Using AI · Growth Library
Ask AI for Failure Cases Before You Ship
Use the model as an adversarial idea generator, then turn useful candidates into real checks
Try this
Describe the intended behavior, constraints, known happy path, and expensive failures. Ask for boundary cases, invalid inputs, state transitions, concurrency or timing issues where relevant, and user misunderstandings. Remove duplicates, verify each candidate against the real system, and write tests for the cases worth keeping.
Check-in: Did AI expose a failure I had not covered, and did I turn that idea into a check rather than merely admire the list?
Evidence: Practical guidance; no evidence-like claim is detected in the current source record.
Review note: AI output is treated only as candidate failure modes. The protocol requires verification and conversion into executable tests or checks before the ideas become QA evidence.
AI can be a cheap source of additional suspicion. That is valuable in QA, provided suspicion eventually becomes a reproducible check.
1. Give it the contract
Describe what should happen and what must never happen. Include meaningful constraints rather than only a feature name.
2. Ask from several failure angles
Request boundary values, missing data, duplicated actions, stale state, wrong permissions, malformed inputs, timeouts, interruptions, and misuse that fits the system.
3. Triage the candidates
Remove duplicates and impossible scenarios. Rank what remains by likelihood, impact, and cost to test.
4. Encode the useful ones
Turn the surviving cases into automated tests, acceptance examples, monitoring rules, or a concise manual checklist. The artifact, not the brainstorm, is the payoff.
Questions to consider
Are generated test cases evidence that a bug exists?
No. They are hypotheses about where the system could fail. Reproduce or validate the condition before treating it as a defect.
What context helps most?
State the contract, boundaries, user roles, inputs, outputs, integrations, and known costly failures. Generic prompts produce generic edge cases.
Maintenance record
Review history
Current status: Reviewed. An editorial or evidence review is recorded and no later event changes that conclusion.
2026-09-15 · reviewed · Brali editorial agent Source: review-registry-using-ai-starters.json
Publish as an AI-assisted QA ideation protocol with an explicit hypothesis-to-test boundary and no claim that model-generated cases are complete or correct.
Browse the review ledger · Challenge or update this hack
Implementation observations can trigger a review, but they cannot change an evidence conclusion by themselves. Commercial relationships do not control review status or outcomes.
Continue from here
Choose the next useful path.
Article versions
Brali keeps substantive article history visible. Later reviews may refresh wording, sources, examples, or boundaries without silently replacing the record.
- Version 2026-09-15: first recorded publication in the migrated Brali corpus.
- Evidence review 2026-09-15: reviewed by Brali editorial agent; evidence state is
practical.
Canonical source record · Evidence state: practical.