Yesterday you ran six boundary values against the sign-in and watched the behaviour change at exactly 8 characters. Today you find a real bug. Not a planted screenshot, not a quiz. You are going to catch it yourself, with yesterday’s technique, and then write the report.
The hunt
The Tumble Kitchen discount note promises: IRIE20 gives 20% off orders of 10,000 JMD or more. “Or more” means the boundary is 10,000 exactly, and yesterday you learned where to stand.
- Open Tumble Kitchen.
- Add the Full Jerk Combo (8,200) and the Baked Cheese Patty (1,800). Subtotal: exactly 10,000 JMD.
- Apply IRIE20.
- Read the discount line.
The promise says you qualify. The store disagrees. Add any other dish so the subtotal goes over 10,000 and apply again, and the discount appears. The code behind this checks “more than 10,000” when the promise says “10,000 or more”. One character in a comparison, and every customer who lands exactly on the threshold is short-changed. Boundary bugs are money bugs, and no amount of casual clicking would have found this one. Your technique did.
Now the report
A bug found and badly reported is a bug that does not get fixed. Two reports for the same issue:
Report A: “Discount not working.”
Report B: “IRIE20 gives no discount when the cart total is exactly 10,000 JMD. Steps: add Full Jerk Combo and Baked Cheese Patty (subtotal 10,000), apply IRIE20. Expected: 2,000 JMD discount, per the stated rule ‘10,000 or more’. Actual: discount shows 0 JMD. Works correctly at 10,001+. Screenshot attached.”
The first one starts an argument. The second one gets fixed the same afternoon, because the developer can reproduce it without asking you a single question. That is the bar for every report you file.
The shape I use, every single time
Title: [Area] What happens, under what condition
Steps: Numbered, exact data included
Expected: What the promise says should happen
Actual: What actually happened, in plain words
Evidence: Screenshot, recording, or the failing request
Environment: Browser + version, device, where you saw it
Severity: How badly it breaks the product
Priority: How urgently it should be fixed
Impact: Who is affected, and how often
Copy that shape into your notes; you will use it for years.
Two of those fields trip up every new tester, so here is the difference. Severity is impact, priority is urgency, and they do not always match. A typo in the homepage headline is low severity and high priority. A crash in a report only one admin runs each December is high severity and low priority. Our discount bug is a solid medium-high on both: it costs customers real money, on a path plenty of shoppers will hit.
Habits that change how your reports land
- Reproduce it twice before you file it. If you cannot, say so honestly, “saw it once, could not reproduce”, instead of filing a vague ticket.
- One bug per report. Two issues in one ticket means one gets forgotten.
- Include the exact data. “A cart of exactly 10,000” is the whole bug here. A report without that number is useless.
- Say who is affected. “Every customer landing exactly on the threshold” tells the team this is worth fixing now.
Do this today
Write the full report for the bug you just found, in the shape above, in your own words. Then check yours against my Report B further up: the exact totals should be in there, and so should the works-at-10,001 detail, because that detail tells the developer precisely which comparison to look at.
Then take it one step further: my bug report builder scores your report live against what reviewers actually look for, and it has more practice scenarios when you want another hunt. My full write-up on reports and triage is here: how to write bug reports and triage defects.
Tomorrow: the store lies to you on the screen while the data underneath goes wrong, and you catch that too.