Field-tested prompts for QA: test cases, test data, bug reports, failure analysis, Playwright tests. Copy, replace the part in square brackets, paste into your AI assistant.
Bugs and failures
Analyse a CI failure
Find the likely cause of a red test from its log.
Here is the log of a test failing in CI. Analyse it and answer:
1. The most likely cause, in one sentence.
2. Is it a real bug, a flaky test or an environment problem? Explain the clues that lead you to think so.
3. The 3 checks to run to confirm it.
4. A suggested fix, to the test or to the code.
Log:
[paste the log, the stack trace and the test name]
Also provide the merge request diff if you can: the cause is often in the lines that just changed.
Bugs and failures
Structured bug report
Turn a messy description into a clear, reproducible bug ticket.
Turn the description below into a structured bug report:
- Title (under 80 characters, describing the symptom)
- Environment (browser, device, version, test account)
- Numbered steps to reproduce
- Actual result
- Expected result
- Suggested severity (blocker, major, minor) with a one-line justification
- Missing information to ask the reporter for
Description:
[paste the description, the message or the screenshot]
Test design
Test cases from a user story
Turn a user story into complete test cases, edge cases included.
You are a senior QA engineer. Based on the user story below, write the test cases.
For each case: an ID, a title, the preconditions, numbered steps, the expected result and a priority (high, medium, low).
Cover the happy path, alternative paths, error cases and edge cases (empty values, maximum values, special characters, insufficient permissions).
Finish with the list of questions to ask the product owner about ambiguous points.
User story:
[paste your user story and its acceptance criteria]
Always read the list of questions: that’s often where the real gaps in the specification are hiding.
Review and exploration
Exploratory testing charter
Prepare a 60-minute exploratory session focused on risks.
Prepare a 60-minute exploratory testing charter for the feature below.
Provide:
- the mission, in one sentence;
- the 5 main risks to explore, from most to least severe;
- for each risk, 3 concrete test ideas (data, actions, conditions);
- useful heuristics (for example: interrupt, repeat, go too fast, switch language);
- a session notes template.
Feature:
[describe the feature and its context]
Test design
Acceptance criteria in Gherkin
Write Given / When / Then scenarios ready for Cucumber or Playwright-BDD.
Write the acceptance criteria for the feature below in Gherkin, in English (Given / When / Then).
Rules:
- one scenario per business rule, with an explicit title;
- use a Scenario Outline with Examples when only the data changes;
- no UI details (no "click the blue button"): describe the behaviour.
Feature:
[describe the feature]
Test data
Test data set
Generate realistic and tricky data for a form or an API.
Generate a test data set in JSON format for the schema below.
Include:
- 5 valid, realistic records (names, addresses and phone numbers);
- 10 invalid records, each with a "reason" field explaining what is wrong;
- edge cases: maximum length, accented characters, emojis, leading and trailing spaces, HTML and SQL injection.
Don't use any real personal data.
Schema:
[paste the schema or the list of fields]
Invalid data is as useful as valid data: it’s what finds validation bugs.
Review and exploration
Review a test suite
Spot tests that are useless, fragile or assert nothing.
You are reviewing the test code below. For each test, flag:
- missing or weak assertions (the test would pass even if the feature were broken);
- sources of flakiness (fixed waits, execution order, shared data, network dependency);
- duplicates;
- important cases that aren't covered.
Rank your remarks by severity and suggest corrected code for the most severe ones.
Code:
[paste the tests]
Automation
Write a Playwright test
Go from a scenario to a readable, robust Playwright test.
Write a Playwright test in TypeScript for the scenario below.
Constraints:
- accessible selectors (getByRole, getByLabel, getByText), never XPath or CSS classes;
- no fixed waits (no waitForTimeout): use web-first assertions (expect(...).toBeVisible());
- an independent test that sets up its own data;
- clear step names with test.step.
Scenario:
[describe the scenario, the URL and the data]
Run the test before reviewing it: a generated test that has never run is only a draft.
The best prompt is still a good tester
AI is fast, but it gets things wrong with confidence. Review every generated case, data set and test before you rely on it.