AI as your second set of eyes.
Turn AI into the reviewer you can't be for your own work.
You cannot effectively review your own test coverage. The same assumptions that shaped what you tested also shape what you overlook. The Persona Technique gives you a second reviewer without waiting on a teammate's calendar, but only if the persona is specific.
| Persona | What it's good for |
|---|---|
| Security-obsessed reviewer | Auth flows, permission boundaries, input sanitization |
| First-time user, no context | Onboarding, empty states, unclear labeling |
| Angriest possible customer | Refunds, cancellations, anything with money attached |
| Power user in a hurry | Keyboard shortcuts, bulk actions, workflow shortcuts |
"Review my test cases" gets a polite summary. "Review these as a reviewer who assumes every user is actively trying to break the checkout flow" gets you gaps you'd have shipped past.
The BCU Framework.
Start with what the business cannot afford to break.
Define the promise
What does this feature promise to deliver to the user, in one plain sentence?
Find the BCUs
The scenarios that, if they fail, mean the promise wasn't kept.
Rank by risk
Which BCU is most likely to fail, and most costly if it does?
Anchor the strategy
Build the test suite around BCUs first, everything else second.
A checkout flow's BCU isn't "user adds item to cart." It's "user with a valid card completes payment and gets a confirmation," the one moment the entire business model depends on going right.
I'm about to build a test strategy and I want to start from the right place, not the feature list. Feature: [describe what it does] What it promises the user: [one plain-English sentence on the core value this delivers] If this feature completely failed in production tomorrow, what's the smallest list of things that would actually embarrass the business or break trust with users, not everything that could theoretically go wrong, just the handful of scenarios where failure means the product broke its promise? For each one, give me: what it is, why it's on this list and not just a nice-to-have, and one thing that could realistically cause it to fail at launch. Keep the list short. If you're listing more than eight things, you're not filtering hard enough, push back and cut it down yourself.
Find the promise first.
Pick a real feature from your product. Write its business promise in one sentence, then run the What Can't Break prompt. Rank the resulting list by risk, and identify which one you'd test first if you only had one day.
The two takeaways:
- The real failure mode: not missing risks, but refusing to cut them. Every risk feels real once you've named it, so a strategy that protects against everything protects against nothing well
- The real skill: saying no to scenarios that are real but not critical. That's a judgment call, not a checklist
Where AI helps: it feels no loyalty to a scenario it just generated. Ask it to defend every item on its list and it will cut its own work.
Check yourself: take your current test plan for something you're working on. Could you defend, out loud, why each item on your "must test" list would actually embarrass the business if it broke, not just that it's a real bug? If you can't defend an item that way, it's probably P1, not P0.
This is one piece of a bigger transition.
Test strategy and stakeholder communication are core skills in the 90-day path from manual tester to AI-augmented QA engineer. Guide 3 walks the full transition: skill gap assessment, portfolio projects, and a real Playwright build from scratch.
See the full transition roadmap →The Persona Technique, with four ready-to-use reviewer angles
The four-step BCU Framework
A real prompt for defining BCUs on any feature
Visual QA & Accessibility.
- Two manual checks that catch most real accessibility bugs
- No specialist tools required
- Backed by a real WCAG 2.1 AA audit: 16+ findings, fixed