What this prompt does
This prompt makes the model act as a senior QA automation engineer and convert a manual QA checklist into a maintainable automated suite, returning working tests rather than pseudocode. Four placeholders steer it: [framework] (the test framework), [app_type] (what is being tested), [selector_strategy] (how elements are located), and [qa_cases] (the manual checklist to convert).
The structure works because the trap when converting manual QA is automating everything, including cases cheaper to eyeball. By asking it to prioritise [qa_cases] by risk times frequency and do the highest-value ones first, name each test as an observable behaviour, use shared fixtures and a page-object layer, adopt [selector_strategy] over brittle CSS/XPath, flag cases that should stay manual with a reason, and note where each test belongs in CI, the prompt builds a small stable suite rather than hundreds of brittle tests nobody trusts. Targeting [app_type] shapes the helper layer to the kind of UI you are testing, and pasting real [qa_cases] is what lets the prioritisation reflect your checklist rather than a generic assumption.
When to use it
- You have a manual QA checklist and want it turned into an automated regression suite.
- You want cases prioritised by risk and frequency, not automated indiscriminately.
- You need tests named as observable behaviours rather than implementation details.
- You want a shared fixture and page-object layer to cut duplication.
- You need a robust
[selector_strategy]so the suite survives refactors. - You want honest flags on cases that should stay manual, with reasons.
Example output
Expect a prioritised list first (the [qa_cases] ranked by risk times frequency), then automated tests in [framework] for [app_type] covering the highest-value cases, using shared fixtures, a page-object or helper layer, and [selector_strategy] for locators. Alongside is a keep-manual list naming the cases better left to humans (exploratory, visual judgment, A/B-dependent) with a reason for each, plus a short note on where each automated test belongs in the CI pipeline.
Pro tips
- Be honest about the keep-manual list — a small stable suite of high-risk flows beats hundreds of brittle tests nobody trusts.
- Use
[selector_strategy]like data-testid and role-based locators instead of brittle CSS/XPath so the suite survives UI refactors. - Paste the real
[qa_cases]so prioritisation reflects your actual checklist, not a generic guess. - Name tests by observable behaviour, not implementation, so they stay meaningful as the code changes underneath.
- Lean on the shared fixture and page-object layer to cut duplication; copy-pasted setup is what makes automated suites rot.
- Start with the top of the risk-times-frequency list and ship those first, so the suite is delivering value before you reach lower-priority cases.
- Use the CI-placement note to decide what runs on every PR versus a nightly job, keeping the fast feedback loop genuinely fast.
