AI QA Checklist Prompts: Catch Mistakes Before They Ship

The most common QA failure isn't a bug. It's someone shipping a thing that looked fine in the meeting and fell apart in the real world because nobody wrote down what "done" actually meant. AI QA checklist prompts won't fix your process if your process is vibes and hope. But if you have real acceptance criteria, actual test evidence, and a human who owns the outcome, they'll help you catch the dumb stuff faster.

That's the pitch. Structural coverage, gap spotting, edge-case brainstorming. Faster prep. Not a replacement for testing. Not a substitute for judgment. Not a sign-off machine.

Here's how to use them.

The formula every AI QA checklist prompt needs

Before the templates, here's the pattern that makes these work. Every good QA prompt gives the AI four things: what you built, what it was supposed to do, who it affects, and what "bad" looks like.

Without those inputs, the output is a generic checklist you could have Googled. With them, you get something scoped to your actual work.

The formula:

"You are a QA reviewer. I will give you [what it is]. The acceptance criteria are [criteria]. The users affected are [audience]. Flag gaps, missing edge cases, and anything that could cause [failure type]. Format as a checklist with severity."

That's it. Everything below is a variation on this shape. The more specific you are going in, the more useful the output coming out. Rule #13 in Don't Replace Me calls it plainly: garbage in, garbage out. Vague requirements create vague QA. Don't ask the model to invent what you haven't defined.

One more thing before the prompts: Do not paste customer PII, employee records, credentials, confidential strategy, contracts, legal disputes, security vulnerabilities, unreleased product details, financial forecasts, HR issues, medical or safety information, private client conversations, or sensitive personal information into any AI tool that hasn't been approved by your organization for that data. Summarize. Anonymize. Ask your IT or security team if you're unsure.

10 AI QA checklist prompts you can use right now

Prompt 1: Turn acceptance criteria into a QA checklist

Use this when you have written acceptance criteria and need to turn them into testable steps before you hand off to QA or test it yourself.

You are a QA engineer. Here are the acceptance criteria for [feature name]:

[paste criteria]

Convert these into a step-by-step QA checklist. For each item, include:
- What to test
- Expected result
- How to verify it passed
- Severity if it fails (critical / high / medium / low)

Flag any criteria that are ambiguous or untestable as written.

If your acceptance criteria are vague, fix them first. Check the prompts at /blog/ai-acceptance-criteria-prompts-stop-shipping-vague-work/ before you run QA on work that isn't clearly defined.

Prompt 2: Find missing edge cases

Use this when you've got a working checklist and want to pressure-test it for things nobody thought of.

You are a QA engineer reviewing this checklist for [feature or workflow]:

[paste checklist]

Identify missing edge cases, including:
- Empty or null inputs
- Boundary conditions (minimum, maximum, zero values)
- Concurrent user scenarios
- Error states and failure paths
- Accessibility and device/browser variation
- What happens if a step is skipped or done out of order

Output as additional checklist items with severity.

Don't treat what comes back as exhaustive. The AI doesn't know your infrastructure, your user base, or your historical failure modes. Use it to jog your thinking, not replace it.

Prompt 3: Check copy and content before launch

Use this for marketing copy, UI text, error messages, emails, or any customer-facing content that ships with a build.

You are a content QA reviewer. Review the following copy for [page / email / UI element]:

[paste copy]

Check for:
- Spelling and grammar errors
- Broken or placeholder text (e.g. "lorem ipsum," "[INSERT NAME]," "TBD")
- Inconsistent terminology or brand voice
- Missing CTAs or instructions
- Anything that could confuse or mislead a user
- Tone mismatches with the surrounding context

Flag each issue with location and severity.

A note on this one: if the copy references prices, legal terms, compliance language, or regulated claims, a human with the right expertise reviews it. Not the model.

Prompt 4: Review a design handoff

Use this when you're receiving a design file and need to check completeness before development starts.

You are a design QA reviewer. Here is the design handoff for [screen or flow]:

[describe or summarize the design, do not paste proprietary files]

Check for:
- Missing states (loading, error, empty, success)
- Mobile and responsive considerations
- Accessibility issues (color contrast, focus states, alt text needs)
- Inconsistencies with the design system or existing components
- Anything a developer would need that isn't documented

List gaps with notes on what needs to be resolved before build starts.

Pair this with your actual design system documentation. The AI doesn't know your component library. You do.

Prompt 5: Pressure-test a spreadsheet or report

Use this when a spreadsheet or report is being used to make decisions or sent to stakeholders.

You are a data QA reviewer. I will describe a spreadsheet or report used for [purpose]:

[describe structure, data sources, formulas, and audience, summarize only, no confidential data]

Review for:
- Formula logic errors or circular references
- Missing data sources or broken links
- Totals that don't add up or filters that exclude rows
- Misleading visualizations or axis labels
- Assumptions that aren't documented
- Data that needs a date or version stamp

Output a checklist of things to manually verify before this goes to [audience].

This prompt works on the structure and logic. The actual numbers need human verification against source data. Always.

Prompt 6: Check customer-impacting workflow changes

Use this before you change any process that touches customers: order flows, account management, notifications, billing, onboarding.

You are a QA reviewer for customer-facing workflows. Here is a description of a change to [workflow name]:

[describe the change, what triggers it, who it affects, and what the old behavior was]

Generate a QA checklist covering:
- Happy path verification
- Rollback or undo behavior
- What customers see vs. what they used to see
- Communication or notification impacts
- Edge cases where the change might behave unexpectedly
- Any dependency on third-party systems

Flag items that require testing in a staging environment before production.

If this workflow touches billing, contracts, or compliance, escalate to the right team before shipping. The checklist won't catch regulatory gaps. A qualified human will.

Prompt 7: Create a regression checklist

Use this when a change to one area might have broken something else.

You are a QA engineer building a regression checklist. A change was made to [component or feature]. Here is what changed:

[describe the change]

Here are the areas of the product that interact with this component:

[list related features or integrations]

Create a regression checklist covering:
- Core functionality of the changed component
- Adjacent features that could be affected
- Integration points with [list systems]
- Data flows that pass through this component
- User permissions and role-based behavior

Prioritize by likelihood of impact and severity if broken.

The workflow audit prompts at /blog/ai-workflow-audit-prompts-find-the-bottlenecks/ can help you map what connects to what before you run regression testing.

Prompt 8: Summarize QA findings for stakeholders

Use this after testing is done, when you need to brief a non-technical audience.

You are a QA lead writing a findings summary for [stakeholder audience]. Here are the raw QA findings:

[paste findings, anonymized, no PII, no confidential data]

Write a stakeholder summary that includes:
- Overall status (go / no-go / conditional)
- Number of issues by severity
- Top 3 issues and why they matter
- Issues resolved vs. open
- Risks if we ship with known open issues
- Recommended next steps

Keep it under one page. Use plain language.

The summary is a communication tool. The underlying findings document is the record of truth. Don't let the summary replace the detail when a real decision is being made.

Prompt 9: Decide what needs human, legal, security, or privacy review

Use this when you're not sure what to escalate.

You are a risk reviewer. Here is a description of what we're shipping:

[describe the feature, change, or workflow]

Flag anything that likely needs review from:
- Legal (contracts, terms, regulated claims, intellectual property)
- Security (authentication, data access, API permissions, sensitive data storage)
- Privacy (personal data collection, consent, data retention, third-party sharing)
- Finance (billing, pricing, tax implications, financial reporting)
- HR (employee data, performance management, hiring decisions)
- Customer leadership (high-impact customer experience changes)
- Accessibility (WCAG compliance, assistive technology)

For each flag, note why it might need review and who should be looped in.

This prompt is a triage tool, not a compliance assessment. If something gets flagged here, you escalate to the right expert. You do not use the AI's answer as the review.

The risk assessment prompts at /blog/ai-risk-assessment-prompts-check-the-blast-radius/ go deeper on this if you need to map out the blast radius before you escalate.

Prompt 10: Final pre-ship sanity check

Use this in the last hour before you go live.

You are a QA lead running a final pre-ship check for [feature or release name].

Here is a summary of what we built, what we tested, and what's still open:

[describe the build, test coverage, open issues, and deployment plan]

Run through this final checklist:
- All acceptance criteria verified with evidence (screenshots, logs, or test records)?
- Open issues documented with severity and owner?
- Rollback plan documented and tested?
- Stakeholder sign-off received and recorded?
- Customer communication drafted if needed?
- Data migration or cleanup steps verified?
- Monitoring or alerting set up post-deploy?
- On-call or support team briefed?

Output a go / no-go recommendation with reasoning. Flag anything missing.

The recommendation is a prompt, not a decision. A human makes the call. The AI helps you make sure you haven't forgotten something obvious at 4pm on a Friday.

What AI QA checklist prompts can't do for you

They can't tell you if the test actually passed. They can't replace a staging environment. They can't read your logs. They don't know what your product actually does in production, who your edge-case users are, or what your regulatory environment requires.

They're fast at structure. They're decent at spotting gaps in what you've written. They will confidently generate checklist items that sound complete and aren't. That's the trap. A polished checklist is not the same as test coverage.

The requirements gathering prompts at /blog/ai-requirements-gathering-prompts-stop-starting-vague/ are worth running before QA if the definition of "done" is still fuzzy. You can't test what you haven't defined.

And when you find something bad: severity, likelihood, owner, date, rollback plan, escalation path. Write it down. Not in a chat window. In a place your team can find it.

The human value in QA is knowing which defects actually matter, which edge cases are dangerous, and when "looks fine" is not good enough. The AI gets you to the checklist faster. You decide if the checklist is right.

Frequently asked questions

Can AI write a QA checklist from scratch?

It can generate a plausible-looking checklist from any description you give it. The problem is "plausible-looking" and "actually covers your product" are not the same thing. Use it to build structure from your real acceptance criteria, then have a human with product knowledge fill the gaps. Never ship based on a checklist the AI generated without verified requirements behind it.

Is it safe to paste test cases and bug reports into ChatGPT?

It depends what's in them. If they contain customer PII, employee data, credentials, security vulnerabilities, or confidential product details, do not paste them into an unapproved AI tool. Summarize the structure and anonymize the content. Ask your IT or security team what your organization's policy is before you assume it's fine.

How do I make AI QA prompts more accurate?

Give them more context: the acceptance criteria, the user type, the failure modes you're worried about, and the environment it runs in. Vague input produces vague output. The more you tell it about your actual constraints, the more useful the checklist becomes. See the prompts for acceptance criteria if you need to define those first.

Should AI make the go/no-go call before launch?

No. The AI can run a sanity check and flag missing items. The launch decision belongs to a named human who owns the outcome. Use Prompt 10 to make sure nothing obvious was missed. Then a person signs off, with the date and their name on it.

What's the biggest mistake people make with AI QA checklists?

Treating a complete-looking checklist as proof that quality was checked. The checklist is a starting point for testing, not evidence that testing happened. Real QA produces screenshots, logs, test records, and documented results. A checklist is the plan. Evidence is the outcome.

Do I need to tell legal or security about everything I ship?

Not everything, but more than most teams think. Anything touching authentication, personal data, billing, regulated claims, employee information, or significant customer-facing workflow changes should have at least a quick conversation with the right function. Prompt 9 is designed to help you triage what needs escalation. When in doubt, ask. The cost of a five-minute conversation is lower than the cost of a compliance incident.