Act as a senior QA engineer reviewing a change before release. Inputs: [FEATURE REQUIREMENTS] [USER FLOWS] [TECHNICAL CONTEXT] [ACCEPTANCE CRITERIA]
[KNOWN RISKS] Create a release-focused QA package. Start with a concise assumptions-and-questions list; ask up to 3 clarifying questions only if a missing input prevents testing a material behavior. Then produce: 1. A risk matrix with severity, likelihood, rationale, and the test level that should catch each risk. 2. A test-case table with ID, preconditions, test data, steps, expected result, priority, and type (smoke, regression, integration, accessibility, security, or exploratory). 3. At least 12 test cases covering happy path, validation, permissions, empty states, retries/timeouts, duplicate submissions, concurrency or stale data where relevant, browser/device behavior, and rollback or recovery behavior. 4. Two automation candidates. For each, provide runnable-looking test pseudocode or code in [TEST FRAMEWORK], explain fixtures/mocks, and identify assertions that prove behavior rather than implementation details. 5. A release gate checklist and a short list of defects that should block launch. Trace every test to a stated requirement, flow, or labeled assumption. Do not invent endpoints, database fields, test accounts, or expected behavior. Mark untestable or ambiguous requirements explicitly. Before answering, check that negative cases are not merely duplicates of happy paths and that expected results are observable to a user, API consumer, or system operator.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [FEATURE REQUIREMENTS] | Paste the feature description, scope, and business rules. | Customers can pause a monthly subscription from account settings; the pause begins at the next billing date and lasts one to three months. |
| [USER FLOWS] | Describe the user journeys and roles affected by the change. | Account owner pauses a plan; support agent views status but cannot change it; customer resumes before the pause begins. |
| [TECHNICAL CONTEXT] | List relevant platforms, integrations, APIs, data handling, and environments. | React web app, Stripe subscriptions, REST API, PostgreSQL, Chrome and Safari supported. |
| [ACCEPTANCE CRITERIA] | Paste the agreed acceptance criteria or definition of done. | Show next billing date before confirmation; prevent pausing annual plans; send one confirmation email; resuming removes the pending pause. |
| [KNOWN RISKS] | List prior defects, fragile areas, deadlines, or risks already known. | Prior webhook delays created mismatched billing statuses; release is two days before month-end. |
| [TEST FRAMEWORK] | Name the test framework and language, or write “not chosen.” | Playwright with TypeScript |
How to use
- Paste the feature materials and include exact rules that are easy to overlook, such as time zones or role permissions.
- Check every assumption against the product owner or engineer before treating it as a requirement.
- Run the smoke cases in the release environment and keep exploratory testing focused on the highest-risk matrix items.
- Follow up with: “Convert cases QA-003, QA-007, and QA-011 into Playwright tests using these selectors and API fixtures: [DETAILS].”
Variations
Bug reproduction
Use when a reported defect is intermittent or poorly specified.
Help me turn this report into a reproducible QA investigation: [BUG REPORT]. The affected environment is [ENVIRONMENT], and available evidence is [LOGS OR SCREENSHOTS]. Produce a minimal reproduction plan, variables to isolate, expected versus actual behavior, diagnostic data to collect, and likely failure boundaries. Include three competing hypotheses, but label them as hypotheses. Do not claim root cause without evidence. Check that each step can be performed by another tester.
API contract tests
Use when validating a service endpoint or integration.
Create API contract test cases for [ENDPOINT OR API SPEC] used by [CLIENTS]. Include authentication, required and optional fields, types, null and empty values, boundary values, idempotency, pagination, error schema, rate-limit behavior, and backward compatibility. Output a table plus examples in [TOOL OR LANGUAGE]. Do not invent fields or status codes; identify omissions in the specification. Verify that every assertion is tied to the published contract.
Accessibility pass
Use before release for an interface change.
Plan an accessibility test pass for [SCREEN OR FLOW] built with [TECHNOLOGY]. The intended users and key interactions are [INTERACTIONS]. Produce manual checks for keyboard navigation, focus order, visible focus, semantic names and roles, errors, form labels, dialogs, zoom/reflow, contrast, and screen-reader announcements. Include expected outcomes and recommended tools. Do not certify WCAG conformance from a description alone; identify what requires testing with real assistive technology.
Tips
- Test the state transition, not just the screen: subscriptions, approvals, and permissions commonly fail after the apparent confirmation succeeds.
- Use production-like time zones and clock boundaries for billing, scheduling, and expiry features; a test run at midday often misses the release risk.
- For automation, assert the user-visible result and durable system state, then isolate third-party behavior with explicit mocks or test fixtures.
- Treat an ambiguous acceptance criterion as a defect in the specification, not an invitation to guess what engineering intended.
FAQ
Can AI write my automated tests?
It can draft useful tests when you provide the framework, selectors, fixtures, and intended behavior. Run and review them because invented helpers, selectors, and assumptions are common.
How many test cases should I create?
Cover distinct risks rather than targeting a fixed number. A small high-risk change may need more depth than a large but isolated UI copy change.
Does this replace exploratory testing?
No. Use the plan to focus exploratory work on surprising states, integration delays, and user behavior that requirements did not describe.