Act as a senior QA engineer and test automation reviewer. I need to test [FEATURE OR SYSTEM]. The requirements and acceptance criteria are [REQUIREMENTS], the technical context is [TECHNICAL CONTEXT], and the change or code under review is [CODE OR CHANGE]. My test environment and constraints are [TEST ENVIRONMENT]. Create a risk-based test package, grounded only in the material I provide. Deliver it in this order:
1. Scope and assumptions: identify in-scope behavior, out-of-scope behavior, ambiguous requirements, dependencies, and the three highest release risks.
2. Test matrix in a table with ID, scenario, setup/test data, steps, expected result, priority, and test level (unit, integration, API, UI, end-to-end, or exploratory). Cover happy paths, validation, boundary values, null or empty values, permissions, state transitions, concurrency or retries where relevant, error handling, and backward compatibility.
3. Exploratory charters: give three 20-minute sessions aimed at likely defects rather than scripted repetition.
4. Automation recommendation: state what belongs in unit versus integration versus end-to-end coverage, and why. If I supplied code, provide runnable test code in [LANGUAGE AND TEST FRAMEWORK], with setup, assertions, and a short explanation. Do not claim code was executed.
5. Release gate: list must-pass checks, useful monitoring signals, and a rollback trigger appropriate to this change.
Do not invent endpoints, schemas, business rules, test results, or dependencies. Mark unknown behavior as a question or assumption. Before answering, check that each expected result traces to a stated requirement and that test cases are not duplicates with different wording. Ask up to 3 clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [FEATURE OR SYSTEM] | Name the feature, service, or workflow being tested. | Password-reset API and web form |
| [REQUIREMENTS] | Paste acceptance criteria, user stories, API contracts, or expected behavior. | A user can request a reset email; tokens expire after 30 minutes and can be used once; responses must not reveal whether an email exists. |
| [TECHNICAL CONTEXT] | Describe architecture, integrations, data model, and relevant users or roles. | Node API, PostgreSQL, SendGrid sandbox, React form; authenticated and anonymous users may request a reset. |
| [CODE OR CHANGE] | Paste the diff, code, pull request summary, or change description. | New POST /password-reset/request endpoint, token table migration, and React confirmation screen. |
| [TEST ENVIRONMENT] | State available environments, test data limits, browsers, devices, and release constraints. | Staging has mail sandbox and seeded users; Chrome, Firefox, and mobile Safari must be covered. |
| [LANGUAGE AND TEST FRAMEWORK] | Name the language and testing framework for any code examples. | TypeScript with Vitest and Supertest |
How to use
- Paste the acceptance criteria and the actual change, then state integrations and any compliance or release constraints.
- Check every expected result against the requirement; add a requirement before treating an unstated behavior as a defect.
- Run the highest-risk API or integration tests before spending time on broad UI regression.
- Follow up with: “Turn test cases T03, T07, and T11 into Vitest tests using this existing fixture pattern: [FIXTURE].”
Variations
Bug reproduction
Use this when a reported defect is incomplete or hard to reproduce.
Help me turn this bug report into a disciplined reproduction and investigation plan. Bug report: [BUG REPORT]. System context: [SYSTEM CONTEXT]. Available logs, traces, screenshots, or data: [EVIDENCE]. Produce: a minimal reproducible scenario, required test data and environment state, numbered reproduction attempts, expected versus observed behavior, hypotheses ranked by evidence, and instrumentation or logs to inspect next. Separate confirmed facts from hypotheses. Do not invent reproduction results. Before answering, identify missing details that prevent a reliable severity or priority assessment.
API contract tests
Use this when validating an API boundary.
Create contract tests for [API ENDPOINT OR EVENT] from this specification: [CONTRACT]. Consumers and dependencies are [CONTEXT]. Use [LANGUAGE AND FRAMEWORK]. Produce runnable test code plus a compact test matrix covering valid requests, required fields, types, enums, boundary values, authentication, error schema, idempotency, pagination or ordering where applicable, and compatibility. State any assumption explicitly. Do not manufacture endpoint behavior beyond the contract. Check that assertions verify status, response shape, and semantically important values rather than only status codes.
Release regression
Use this when selecting a focused regression suite before deployment.
Design a release regression plan for [RELEASE CHANGE]. Relevant workflows are [WORKFLOWS], known risk areas are [RISKS], and available testing time is [TIME]. Return a prioritized checklist grouped into must-pass, should-pass, and monitor-after-release. For each test, include user role, precondition, action, expected outcome, and reason for priority. Include only tests that can plausibly be affected by the change or its dependencies. Identify gaps that cannot be covered in the time available. Do not claim testing occurred or invent production metrics.
Tips
- A test case needs an observable expected result; “works correctly” cannot distinguish a defect from an implementation choice.
- For validation rules, test just below, at, and just above each boundary, plus omitted, null, and malformed values when the interface can receive them.
- Separate unit tests for deterministic rules from integration tests for databases, queues, email, and third parties; end-to-end tests should protect only critical journeys.
- When a requirement is ambiguous, record the question before writing a test expectation; otherwise a test suite can codify an unapproved product decision.
FAQ
Can AI write production-ready tests?
It can draft useful tests, but you must run them and check fixtures, imports, contracts, and project conventions. It cannot honestly claim execution without access to your environment.
Should I paste the whole repository?
Start with the changed code, relevant interfaces, existing test patterns, and requirements. Add more context only if a dependency changes the behavior under test.
How many test cases are enough?
Coverage should follow risk, not a fixed number. Prioritize irreversible data changes, authorization, payments, privacy, core workflows, and failure recovery.