The Write-Up: Product Bug or Test Bug
Every debugging session ends with a verdict and a write-up. The verdict names the owner; the write-up decides whether the fix lands today or bounces back.
Three verdicts, three owners
- App bug → a developer fixes the product.
- Test bug → you fix the test, and leave one line in the PR about the pattern so review catches the next one.
- Environment → whoever owns the pipeline.
Naming the bucket, with evidence, is the deliverable. "It fails sometimes" is not a verdict.
What a developer needs
- Exact steps and data — which SKU, which coupon, which account. Not "a valid user".
- Expected vs actual — one measurable line each.
- Evidence — the trace, screenshot or response body. Attached, not described.
- Environment — browser, CI or local, commit SHA.
- Frequency — 7/50, not "sometimes".
▸ A report that gets fixed the same day
Title: Cart total drops the discount when the cart is edited
after a coupon is applied
Steps: 1. Add SKU-104 (qty 1) 2. Apply SAVE10 — total $35.99
3. Change qty to 2 4. Total shows $79.98 (discount gone)
Expected: $71.98 (10% held) Actual: $79.98
Evidence: trace.zip attached — step 3's PUT /cart responds 200
with discount:null Commit: a8d3c42, chromium headless
Frequency: 10/10 on CI and locallyWhy "cannot reproduce" happens
It happens when you hand over a conclusion instead of evidence. Steps, data, a trace and a frequency leave nothing to bounce.
Grounded in how failure reports get actioned — and bounced — on real teams
All lessons in The Failed Test: Debugging Automation Like a Senior
- The Four Questions That Sort Any Failure
- Reading the Traceback Like a Senior
- Shrinking the Search Space
- Flaky or Broken: Prove It With a Number
- It Only Fails in CI
- The Write-Up: Product Bug or Test Bug