Prompts for software testers who want useful output, not longer output.
Each prompt forces the model to separate assumptions from requirements and make uncertainty visible.
Requirement risk review
Act as a senior QA engineer reviewing the requirement below.
Your goal is NOT to generate test cases yet.
Identify:
1. ambiguous statements,
2. missing business rules,
3. boundary values that are undefined,
4. state or timing dependencies,
5. data dependencies,
6. failure behavior that is unspecified,
7. questions that must be answered before testing.
For every issue, quote or paraphrase the requirement that caused the concern.
Do not invent missing rules. Label assumptions explicitly.
REQUIREMENT:
[PASTE REQUIREMENT]
Edge-case expansion
Using the validated requirement and known business rules below, generate high-value edge cases.
Group them by:
- boundaries,
- state transitions,
- concurrency/race conditions,
- time/timezone behavior,
- authorization,
- invalid or partial data,
- retries/idempotency,
- downstream dependency failures.
For each case include: risk, setup, action, expected behavior, and why the case matters.
Prioritize realistic high-impact cases. Do not create cases unsupported by the requirement.
BDD scenario review
Review these Gherkin scenarios as a test automation lead.
Find:
- duplicated coverage,
- missing negative paths,
- ambiguous Given/When/Then steps,
- implementation details leaking into business scenarios,
- scenarios that are too broad,
- shared preconditions that should be simplified.
Return an improved scenario set and explain each material change.
Automation code review
Review this automated test for correctness, maintainability and flakiness.
Check specifically:
- synchronization/waits,
- selector brittleness,
- assertion quality,
- test independence,
- hidden dependencies,
- cleanup,
- data isolation,
- exception handling,
- unnecessary sleeps,
- retry misuse.
Prioritize defects and reliability risks over style preferences.
For every recommendation explain the failure mode it prevents.
CODE:
[PASTE CODE]
Defect triage
Analyze the defect evidence below.
Separate your response into:
A. verified observations,
B. plausible hypotheses,
C. evidence needed to confirm/refute each hypothesis,
D. next diagnostic steps in the most efficient order.
Do not state a root cause unless the supplied evidence proves it.
EVIDENCE:
[LOGS / STEPS / SCREENSHOTS / REQUESTS]
Why these prompts are structured this wayThe highest-value instruction is often “do not invent.” QA work requires traceability. A plausible answer that silently adds a business rule can create false confidence.