One Queue, Two Names, One Story
Two acceptance criteria in a single story named the destination queue two different ways. Each line read fine alone. The build picked one, and QA filed the other as a Highest-priority defect.
Two acceptance criteria in a single story named the destination queue two different ways. Each line read fine alone. The build picked one, and QA filed the other as a Highest-priority defect.
A defect was closed and unlinked from both its stories the same day. Only a daily status diff caught it — a query run afterwards would have shown a story that simply had one fewer bug.
Scope grew and the calendar shrank in the same release, and the test report did not move. The mechanism that should have turned that into a risk never existed.
A price change and its matching discount were tracked as independent stories. Deploy the first without the second and every subscriber gets a net charge of minus one pound a month.
The QA work I was proudest of mapped to a Level 5 process area — in an organisation with no test policy, no strategy and no monitoring reporting. That gap is the finding.
A cart used a single pricebook, selected automatically, with no decision point anywhere. The exclusion took one line to record — and saved the same question being re-raised every sprint.
A service change with a router update and one without produce different plans. A hardware-adding modify re-runs provisioning; a subscription add-on creates nothing.
One criterion had no implementing code anywhere in the class that owned the calculation. Another read as satisfied while the query quietly dropped every promotion.
An audit found two QA leadership roles indistinguishable in daily practice, and a decision to cut testing taken without either of them in the room. The empty chair is the finding.
Three Highest-priority defects on one new product family, then a second family two days later. Nobody owned the cheapest check there is: add each new SKU to the cart once.