AI prompts for QA engineers

Act as a senior QA engineer reviewing [FEATURE OR CHANGE]. The product context is [PRODUCT CONTEXT], and the acceptance criteria are [ACCEPTANCE CRITERIA]. The relevant interfaces, dependencies, and constraints are [TECHNICAL CONTEXT]. Known risk areas and past defects are [RISK HISTORY].

Produce a QA test package with these sections:
1. Testable requirements: restate each acceptance criterion as an observable pass/fail behavior; flag ambiguity, missing error behavior, and non-testable wording.
2. Risk-based test matrix: ID, scenario, preconditions, test data, steps, expected result, priority (P0-P2), and test type (manual, API, UI, integration, accessibility, performance, security review).
3. Edge cases: invalid and boundary inputs, empty and duplicate states, permissions, concurrency or retry behavior, network/service failure, time zone/date transitions where relevant, and backward compatibility.
4. Automation recommendation: which P0/P1 cases are stable enough to automate, at which layer, and what test isolation or fixtures they require.
5. Exploratory charter: a 30-minute focused session with mission, areas to probe, and evidence to capture.
6. Open questions and release blockers.

Do not invent APIs, UI controls, database fields, thresholds, or business rules. Mark every assumption and write a question instead of filling a gap. For security-sensitive behavior, identify where a security review is needed rather than claiming a feature is secure. Use concise, executable steps and expected results that can be observed.

Before answering, check that every acceptance criterion has at least one positive and one negative or boundary test where applicable, and that every expected result follows from the supplied requirements. Ask up to 3 clarifying questions only if a required input is missing.

Analyze this reported defect: [BUG REPORT]. Environment and build details: [ENVIRONMENT]. Available logs, screenshots, or requests: [EVIDENCE]. Produce a reproduction plan with prerequisites, exact steps, expected versus actual behavior, variables to isolate, likely component boundaries, and evidence to capture. Then list 5 targeted regression tests. Do not infer root cause or fabricate logs. Separate confirmed facts from hypotheses and state what observation would support each hypothesis. Before answering, check that another QA engineer could execute the steps without unstated setup. Ask up to 3 questions only if required inputs are missing.

Design API tests for [ENDPOINT OR OPERATION]. Contract details are [REQUEST RESPONSE CONTRACT], authorization rules are [AUTH RULES], and business behavior is [BUSINESS RULES]. Produce a table of positive, validation, authorization, idempotency, concurrency, pagination, and error-handling cases with request setup, expected status, expected body assertions, and data cleanup needs. Do not make up status codes, fields, or rate limits. Flag missing contract rules. Before answering, ensure each expected assertion is based on supplied documentation and test data does not use real customer information. Ask up to 3 questions only if needed.

Create a release-readiness checklist for [RELEASE]. Scope and acceptance criteria: [SCOPE]. Changes and dependencies: [CHANGES]. Test evidence available: [TEST EVIDENCE]. Include functional coverage, regression areas, browser/device support, migration or rollback checks, observability, accessibility, security-review triggers, known issues, and owner-based exit criteria. Return go/no-go risks ranked by impact and likelihood, but do not declare the release safe or approved. Before answering, verify each checklist item has an evidence source or a named gap. Ask up to 3 questions only if required inputs are missing.