40 copy-paste AI prompts for QA engineers

Most prompts testers try produce disappointing output for the same reason: they ask for help instead of asking for a thing. "Help me test the login page" gets you a lecture about test types. "List 12 ways a session can end unexpectedly during checkout, with the expected behaviour for each" gets you something you can use before lunch.

Every prompt below is written the second way. Copy one, replace the bracketed parts with your details, and paste.

Short version

Specific request, specific format, specific example data. Those three things fix most bad output.
Give the model your real field names, roles, and error codes. Generic input, generic output.
Ask for one kind of thing per prompt. Mixed requests produce shallow answers on all of them.
Tell it to mark what it does not know, instead of guessing.
Review everything. These prompts produce drafts, not deliverables.
Save the ones that work for your product in a shared team file.

How to make any of these work better

Four small habits raise output quality more than switching models.

Paste the real artefact. The whole requirements document, the actual schema, the actual test file. Not a summary of it.
Name the format. "Markdown table with columns X, Y, Z" or "JSON array". Otherwise you get prose you have to reshape by hand.
Force the unknowns to be visible. Add: "If you do not know something, write UNKNOWN rather than guessing." This turns silent invention into a checklist.
Use realistic placeholders. [email protected], https://staging.example.com, real error strings like TypeError: Cannot read properties of undefined (reading 'total'). Concrete input pulls concrete output.

Test case generation (1-10)

1. Convert requirements into cases

You are a senior QA engineer. Below is a requirements document for [feature]. Generate test cases as a markdown table with columns: ID, Title, Preconditions, Steps (numbered), Expected Result, Priority. Expected results must quote exact UI text or error codes from the document. Where the document does not specify, write UNSPECIFIED. Requirements: [paste]

2. Negative cases only

For [feature], generate only negative test cases. Cover invalid input, missing required fields, insufficient permissions, expired or out-of-range values, duplicate submission, and server failure mid-action. State which rule each case tests.

3. Boundary values

List every number, length limit, date range, and quantity in this specification. For each, produce three cases: just below the limit, exactly at it, just above it. Then list limits that are implied but never stated.

4. State transitions

[Feature] has these states: [list]. Build a table of every state-to-state transition. Mark each as allowed or forbidden. For each forbidden one, write the test case that proves the system blocks it.

5. Permission matrix

Our roles are [owner, admin, member, viewer]. Our actions on [resource] are [create, read, update, delete, share]. Produce a role-by-action matrix of expected results, then one test case per cell where access should be denied.

6. Decision table

Turn this business rule into a decision table with every combination of conditions, then collapse rows that produce identical outcomes. Rule: [paste rule].

7. Cases from a bug

Here is a bug we just fixed: [paste]. Write the regression test for the exact bug, plus 4 test cases for closely related paths that the same root cause could also affect.

8. API contract cases

Here is an OpenAPI snippet for [endpoint]. Generate test cases covering required and optional fields, wrong types, extra unknown fields, auth missing and expired, and each documented error code. Spec: [paste]

9. Accessibility pass

For this screen description, list the keyboard-only test cases: tab order, focus visibility, escape and enter behaviour, focus trapping in modals, and what a screen reader should announce for each control. Screen: [describe]

10. Deduplicate a suite

Here are 60 existing test cases. Group them by the rule they actually verify. Identify duplicates, near-duplicates, and cases that test nothing observable. Output the list of cases you would delete and why. Cases: [paste]

Bug reports (11-18)

11. Rough notes into a report

Turn these session notes into a bug report with title, environment, steps to reproduce (numbered, starting from a logged-out state), expected result, actual result, and severity with a one-line justification. Flag anything in my notes that is too vague to reproduce. Notes: [paste]

12. Better title

Rewrite this bug title into a title that states what breaks, where, and under what condition, in under 90 characters. Give me three options. Current title: [paste]

13. Missing information check

Review this bug report as a developer who has never seen the feature. List every question you would have to ask before you could start debugging. Report: [paste]

14. Reproduction steps from a stack trace

Here is a stack trace from production. Suggest the 5 most likely user actions that produced it, ranked by probability, and the data conditions each would require. Trace: [paste]

15. Severity argument

Given this bug and this context — [users affected], [workaround exists yes/no], [data loss yes/no], [frequency] — write a 3-sentence argument for the severity you would assign, and the strongest counter-argument.

16. Duplicate check

Here is a new bug and here are 20 open bugs from our tracker. Identify which existing ones might be the same underlying issue, and explain the connection in one line each. New: [paste]. Existing: [paste]

17. Release notes from fixed bugs

Turn these 12 fixed bug tickets into customer-facing release notes. Plain language, no internal jargon, no ticket IDs, grouped by area of the product. Tickets: [paste]

18. Report quality review

Score this bug report from 1 to 5 on: title clarity, reproducibility, evidence, and scope. Give one concrete improvement per category. Report: [paste]

A note on prompt 11: the model can only structure what you wrote down. The evidence — screenshot, console output, failing network request, browser and OS — still has to come from the session itself. A browser-based reporting tool like Crosscheck attaches those automatically when you file from the page, so the model has more to work with and you type less.

Test data (19-25)

19. Generator script

Write a Python script using Faker with a fixed seed of 42 that generates 500 rows for this schema. All emails must use example.com. Include 5% names over 80 characters and 10% with non-ASCII characters. Output CSV. Schema: [paste]

20. Referential integrity

Extend that script to generate orders where every user_id is sampled from the generated users file, each order has 1-5 line items referencing generated products, and order totals equal the sum of line items. Add an assertion that fails if any foreign key does not resolve.

21. Awkward values set

Give me 25 field values designed to break form validation and display: maximum length, unicode, right-to-left text, HTML-like and SQL-like strings, whitespace only, zero, and negative numbers. Table format with a note on what each tests.

22. Realistic distributions

Describe a realistic distribution for [entity] in a B2B SaaS product: what share of accounts have 1 user, 2-10, 11-100, and 1000+. Then write the generator config that produces that shape.

23. Date and timezone cases

List 15 date and time values that commonly break software: leap day, daylight saving transitions, the Unix epoch, end of month and year, and timezone boundaries. For each, state the correct expected behaviour.

24. Localisation set

Give me test values for name, address, phone, and currency for Japan, Germany, Brazil, and Saudi Arabia, showing how the format differs from the US. Note what each one breaks in a US-only design.

25. Anonymisation review

Here is a description of how we plan to anonymise a dataset for testing: [paste]. List the ways this could still identify a real individual. Do not reassure me.

Risk analysis and planning (26-33)

26. Risk list from a change

Here is a pull request description and diff summary. List the 10 highest-risk areas to test, ranked, with a one-line reason for each. Include areas the change touches indirectly. Diff: [paste]

27. What could go wrong

For [feature], list 15 realistic failure modes, grouped into: data problems, timing and concurrency, permissions, third-party dependencies, and user error. Ignore anything requiring physical access to a server.

28. Regression scope

We changed [component]. Given this list of features that also use it, tell me which need a full regression pass, which need a smoke check, and which can be skipped. Justify each in one line. Features: [paste]

29. Release go/no-go questions

Write the 12 questions a release manager should ask before shipping [feature] to production. Focus on rollback, monitoring, data migration, and feature flags.

30. Test plan skeleton

Draft a one-page test plan for [feature]: scope, out of scope, environments, entry and exit criteria, risks, and the roles involved. Keep it under 400 words and specific to this feature.

31. Coverage gap check

Here are our automated test names for [module]. Reading only the names, tell me what behaviour appears to be untested, and what a name suggests is tested but might not be. Names: [paste]

32. Flaky test triage

Here are the failure logs from a test that fails about 1 run in 8. List the 6 most likely causes ranked by probability, and the cheapest experiment to confirm or eliminate each. Logs: [paste]

33. Post-incident questions

Here is a summary of a production incident. Write the questions for the post-incident review that focus on detection and testing: why did tests not catch it, what signal existed, and what would have caught it earlier. Incident: [paste]

Automation and code review (34-40)

34. Review a test for real assertions

Review this test. For each assertion, say whether it could ever fail if the feature were broken. Flag tautologies, assertions on mocked values, and assertions that only check that something is not null. Test: [paste]

35. Over-mocking check

In this test file, list what is mocked. For each mock, say whether it removes the logic the test claims to verify. Test: [paste]

36. Selector quality

Review these element selectors for stability. Flag any that depend on position, generated class names, or visible text likely to change. Suggest a better selector for each. Selectors: [paste]

37. Wait strategy

Find every fixed sleep or arbitrary timeout in this test file and replace each with a condition-based wait on a specific observable state. Explain what each new wait is waiting for. File: [paste]

38. Test naming

Rename these tests to the pattern: what is being tested, under what condition, with what expected result. Keep them under 100 characters. Tests: [paste]

39. Page object extraction

This test file repeats selectors and login steps. Refactor into a page object with named methods, keeping the tests readable. Do not change what is asserted. File: [paste]

40. Mutation thinking

Here is a function and its tests. Describe 5 small changes to the function that would break its behaviour, and say for each whether the existing tests would catch it. Code: [paste]

Turning this into a team asset

A prompt list stops being generic the moment you add your own product to it.

Copy the ten prompts closest to your daily work into a shared file in your repository.
Add a fixed header to each: your roles, your environments, your error code list, your test case format.
Note which ones produced something useful and which did not.
Delete the ones nobody used after a month.

The team file beats any published list, because it contains the context that makes output specific. The prompts above are the starting shape; your product supplies the substance.

One habit to keep alongside it: never paste real customer data, credentials, or unreleased business information into a tool your company has not approved. That rule applies to all forty of these.

Frequently asked questions

Do these work in any chat tool? Yes. They are plain instructions with no product-specific syntax, so they work in any current chat model. The quality difference between tools is smaller than the difference between a vague prompt and a specific one.

Should I run these in one long conversation or separately? Related prompts work better in one conversation, because the model keeps your requirements and format in context. Start a new conversation when you switch features, so old details do not leak into new output.

How much of the output can I trust? Treat it as a first draft from a fast, literal colleague who has never used your product. Structure and coverage lists are usually good. Anything stated as a fact about your system needs checking.

What if the output is too generic? You did not give it enough specifics. Add real field names, role names, error codes, and a sample of your team's format. Generic in, generic out is the most reliable rule in this whole area.

Is it safe to paste our test code into a model? Check your company policy. Many organisations allow it in an approved enterprise account but not in personal ones. Either way, strip credentials, API keys, and internal URLs before pasting.