Good testing helps an app’s team understand what is broken, how to reproduce it, and how it affects users. Finding something you would design differently is useful feedback, but it does not automatically make it a bug.
Before submitting a report on Testr, make sure you can explain the problem and support it with evidence.
Understand what you’re testing
Read the campaign’s scope and instructions before you begin. Check which features, platforms, and user flows the owner wants tested.
Test against the app’s stated behavior and the campaign’s requirements. Avoid treating your personal preferences as requirements the app has failed to meet.
When the intended behavior is unclear, ask for clarification instead of presenting an assumption as a confirmed defect.
Know the difference between a bug and a feature request
A bug is a problem with how something works. A feature request proposes adding or changing functionality.
- Bug: The profile page says “Changes saved,” but your updated name disappears after refreshing.
- Feature request: The profile page should let users upload a cover photo.
- Bug: Selecting “Download invoice” consistently opens an error page.
- Feature request: The app should support another payment method.
Feature requests can be valuable, but they do not belong in the bug bounty submission flow. Share them through a separate feedback channel if one is available.
For example, an app allowing signup without email verification is not automatically a bug. That behavior may be intentional. Check the campaign’s requirements and explain the actual failure before reporting it. The missing step alone does not justify calling it critical.
Reproduce the problem before reporting it
Try the same steps again. Identify the conditions that trigger the issue, including the account state, device, browser, or app version.
A strong report lets someone else repeat your test and observe the same result.
If the issue happens intermittently, say so. “This happened twice in five attempts” is more useful than claiming it happens every time. Include the conditions you observed without guessing at the cause.
Explain exactly what happened
A good bug report includes:
- A specific title: Name the action and the failure.
- Environment: Device, operating system, browser or app version.
- Preconditions: Anything required before starting, such as being signed in.
- Steps to reproduce: Numbered actions from a clear starting point.
- Expected result: What should happen and why you expect it.
- Actual result: What happened instead.
- Evidence: Screenshots or a recording that supports the report.
- Impact and frequency: Who is affected, what they cannot do, and how often it happens.
Profile name reverts after a successful save
Precondition: Signed in with a test account.
Steps to reproduce
- Open Profile.
- Change the display name.
- Select Save and wait for “Changes saved.”
- Refresh the page.
- Expected
- The new display name remains saved.
- Actual
- The previous name returns despite the success message.
- Frequency
- Reproduced in three out of three attempts.
- Impact
- Users cannot update their display name.
Attach your actual environment details and relevant evidence. Remove passwords, tokens, and private information from attachments.
Match severity to demonstrated impact
Severity should reflect the problem’s actual effect on users. Follow the campaign’s severity definitions where provided.
Explain what is blocked, how broadly it occurs, and whether a workaround exists. Do not inflate severity to make a report seem more important. A clear, accurately described issue is more useful than an exaggerated one.
Before submitting, confirm that your finding is within scope, is not an existing duplicate where reports are visible, and includes enough detail for someone else to investigate.
The goal is to help the team fix a real problem. Report what you observed, show how it happens, and keep feature suggestions separate from bug submissions.