Write a reproducible defect report from the supplied evidence.
Instruction: Produce the actual report, separating observed facts, expected behavior, and unknowns.
All evidence is fictional. In staging build checkout-0.8.3, on the supplied Chrome test image, fixture user qa-buyer-1 has an empty basket. SKU TEST-10 costs $10.00, has stock, and has no tax or shipping. At 14:05 UTC on 12 October 2026, you added two units, applied valid coupon TEN, and clicked Recalculate. The screen and the response for request r-204 both showed total $20.00. Requirement PRICE-7 says TEN deducts 10% from eligible merchandise. The same steps reproduced three times with a fresh basket. You captured screenshot total-r204.png and a sanitized response excerpt containing subtotal 20.00, discount 0.00, total 20.00. No checkout was completed. No other browser was tested; the exact OS and browser version have not yet been recorded.
Updated
Example Answer
I would title the issue around the observable failure and include the requirement, build, fixture, minimal steps, expected amount, actual result, and evidence. Here the expected discount is $2.00 and the expected total is $18.00.
The report below does not claim that a customer was charged incorrectly because checkout was never completed. It also does not claim cross-browser impact. I would record the missing OS and browser version from the test image before handing the report over; their absence is an explicit evidence gap, not a reason to invent versions.
I would attach only sanitized evidence, keeping request identifiers for correlation while excluding cookies, credentials, and personal data. The UI and response agree on the wrong result, which narrows investigation, but does not yet prove the root cause.
Worked defect report
Title: TEN coupon leaves a two-unit TEST-10 basket at $20.00 instead of $18.00
Environment: Staging, checkout-0.8.3, supplied Chrome test image. Exact OS/browser version: not yet recorded. Observation time: 12 October 2026, 14:05 UTC.
Preconditions: qa-buyer-1; fresh empty basket; TEST-10 at $10.00 with stock; zero tax/shipping; valid TEN coupon eligible under PRICE-7.
- Add two units of TEST-10.
- Apply TEN.
- Click Recalculate.
Expected: Subtotal $20.00, discount $2.00, total $18.00.
Actual: UI total $20.00; response r-204 contains subtotal 20.00, discount 0.00, total 20.00.
Reproduction: 3/3 fresh-basket attempts in this environment.
Evidence: total-r204.png; sanitized response excerpt for r-204; PRICE-7.
Impact and limits: Eligible discount is absent before purchase. Payment impact and other browsers are untested. Proposed severity: major pricing defect, subject to team definitions; priority requires release and exposure context.
What the interviewer is assessing
Core checks (1 point each):
- Gives reproducible steps and $18 expected versus $20 actual.
- Includes build, fixtures, 3/3 frequency and sanitized evidence.
- Keeps environment gaps, payment impact and cause explicitly unknown.
Stronger (+1 after all core checks): Helps a junior author improve the report with specific, respectful feedback while keeping unsupported cause and payment-impact claims out.
Acceptable alternatives: Any report template works if an engineer can reproduce and assess it.
Red flags: Writes only “coupon broken,” invents an OS/browser version, or includes secrets in attachments.
Follow-up
The developer cannot reproduce it. What do you do next?
Example response: I would compare the exact build, feature flags, fixture eligibility, coupon configuration, and recorded environment. Then we would replay the minimal steps together and correlate the sanitized request ID with server logs. If the failure depends on state, I would update the preconditions and evidence rather than label the developer response incorrect.
A junior tester wrote only “coupon broken.” How would you coach them?
Example response: I would acknowledge the finding and help them improve it: “Let's add the fresh basket, TEN coupon, $18 expected total, $20 actual result and request ID so another person can reproduce it.” I would explain why payment impact and untested browsers remain unknown, then let them own the revised report. The feedback should improve the evidence without embarrassing the person.
Related Questions
-
easy
-
easy
-
easy
-
easy
-
easy
-
easy