A Form Is a Cheat Sheet, a Blank Page Is an Exercise
A test case form supplies the structure an exercise is supposed to demand. Three exercises I had to rebuild after the tool did the thinking for us.
// how hard can it be?
Case studies and frameworks from real projects. Short sentences. Own mistakes. No theory.
A test case form supplies the structure an exercise is supposed to demand. Three exercises I had to rebuild after the tool did the thinking for us.
Step discount failed three weeks running and the failure class changed every week, because each retest was scoped to whatever the previous week's bugs had named.
One design described postcode matching three times and never decided. Every worked example used a prefix — and a PE1 prefix row silently captures PE10 through PE19.
Four candidate keys were circulating for one lookup — postcode, Service_ID, S-Number and UPRN. The real defect was that the chosen key was one level coarser than the fact it encodes.
Every test case on the project opened by logging into Salesforce as a named user. Then a channel arrived where the customer builds the order on an external site and nobody is logged in at all.
A bundle removed from the cart and added back before submit produced a clean order, a successful billing callout, and a wrong invoice. Nothing in Salesforce showed a problem.
One acceptance criterion said the promotion drops off after three months and the bill reverts to £30, then two bullets later said six months free with month seven at £16.
"6 months free" was written down four times and its starting point three different ways — from purchase, in billing periods, from go-live. The payload omitted the start date its neighbours carry.