Write the observation before the theory
Use a title that describes the visible failure and condition: “Checkout total resets after returning from canceled payment” is searchable and testable. Avoid titles such as “Checkout broken” or a guess like “State-management race condition” unless technical evidence has established that cause.
The report should let a person unfamiliar with the test understand the user goal and consequence. State whether work was blocked, data was lost, money moved incorrectly, a security boundary failed, or the user could recover. Impact helps triage; emotional emphasis does not.
Capture environment and starting state
Record the product build or time, URL or environment, device, operating system, browser and version, viewport, account role, locale, relevant feature flags, and network condition. Include only details that could change behavior, but do not omit the account or data state that made the failure possible.
Describe preconditions separately from steps. “Account has an unpaid order with a saved address” is a precondition. This keeps the reproduction concise and prevents another tester from accidentally starting with a clean state that cannot trigger the issue.
Reduce to the smallest reliable reproduction
Repeat the issue safely, then remove unnecessary actions one at a time. Number each remaining user action and identify the exact step where actual behavior diverges. Use literal labels and values when they matter, but never paste credentials, tokens, private customer data, or real payment details.
Report reproducibility honestly: always, intermittent, once, or not reproduced after retry. For intermittent defects, include timing and sequence observations rather than inventing a frequency from too few attempts.
- Preconditions: the state required before step one
- Steps: the minimal actions that trigger the issue
- Expected: the behavior supported by the requirement or product pattern
- Actual: the observable result, including messages and persisted state
- Recovery: whether refresh, retry, back navigation, or support resolves it
Attach evidence that preserves sequence
Use a screenshot for a stable visual state and a short screen recording when order, timing, focus, animation, or navigation matters. Start the recording close to the reproduction and narrate sparingly. Highlighting can help, but preserve an unaltered view so the evidence remains trustworthy.
Console and network output can accelerate diagnosis when the tester understands it, but redact sensitive headers, request bodies, identifiers, and personal information. A report should never create a security incident in the process of documenting a defect.
Separate severity, priority, and confidence
Severity describes user or system impact. Priority reflects when the organization should act. Confidence describes how strongly the evidence supports the report. Keeping them separate avoids treating a rare but severe observation as unimportant or an obvious cosmetic issue as release-critical.
After a fix, retest using the original environment and steps, then check the surrounding journey. Record the build and result rather than overwriting the original report. The before-and-after evidence becomes a durable regression case.
Frequently asked questions
What is the most important part of a bug report?
Reliable reproduction context is the foundation: starting state, environment, minimal steps, expected behavior, and actual behavior.
Should a tester assign severity?
A tester can propose severity using documented criteria, but product and engineering owners should confirm business priority and release impact.
When is video better than a screenshot?
Use video when sequence, timing, focus, animation, or navigation is necessary to understand the failure. Use screenshots for exact stable states and readable messages.
Primary references
Need narrated evidence from a real journey? Start a RentAHuman QA run.