Every bug bash has that moment.
Someone finds a fail. Someone else says, “Yeah, we never tested that.” Someone else says, “That wasn’t in the AC.”
All three can be true. None of them help the user who hit it.
Happy path is necessary. It’s not a strategy.
If your suite is mostly:
- login works
- add to cart works
- checkout works
…you’ve proven the demo. You haven’t proven the product.
The bugs that hurt reputation live in:
- empty inputs that somehow submit
- max-length fields that truncate silently
- expired sessions mid-flow
- users with the “almost admin” role
- double-submit on a slow network
A coverage checklist that fits on a sticky note
Before you call a feature “cased out,” ask:
| Lens | Question |
|---|---|
| Positive | Does the main flow work with good data? |
| Negative | What happens with bad / missing / forbidden data? |
| Boundary | Limits, zero, one, max, max+1 |
| State | Empty, loading, partial, already-completed |
| Role | Who shouldn’t be able to do this? |
| Interrupt | Refresh, back, timeout, second tab |
You won’t write every lens for every tiny tooltip. You will for money movement, auth, permissions, and anything with “delete” in the name.
Using generation without turning into a case factory
In TestCaseMate you can ask for functional, security, usability, etc. The trap is generating everything every time and drowning the team in near-duplicates.
Rule we follow:
- New risky feature: functional + negative/boundary focus, maybe security if auth/PII
- UI copy change: light functional, maybe usability
- Regression pack: don’t regenerate — reuse and prune
Credits are monthly on purpose. Scarcity keeps you honest.
The review question that matters
For every generated case, ask: If this fails, do we learn something we don’t already learn from another case?
If no, delete it. Coverage isn’t a word count.
Generate a wider first pass, then prune hard.
Open TestCaseMate →
