Tests & QA
Coverage percentages are easy to raise and easy to fake. What is hard is knowing which tests would actually catch tomorrow's bug, which ones assert the implementation rather than the behaviour, and which ones exist only to make the number go up. The prompts below are written for that judgement. They ask for concrete failure cases rather than reassurance, they force a verdict on whether a test earns its maintenance cost, and several instruct the model to say when a suite is already adequate instead of inventing gaps. Use them on code you are about to ship, a test that fails once a week, or a suite you have stopped trusting.
36 prompts in 5 groups
Tests & QA21 categories
Finding coverage gaps
Working out which behaviours, edge cases and error paths nothing currently checks.
- Audit this suite for untested behaviourLongYou wrote tests and want to know what you did not think of.
- Write test cases from acceptance criteriaLongA story is ready for QA and the criteria need turning into concrete checks.
- Find property-based test ideasLongCode with a large input space where example tests only scratch it.
- Test the error pathsLongWhen every existing test exercises the happy path.
- Brainstorm edge cases for this featureLongBefore writing tests, to widen the input space you are imagining.
- What is untested here?ShortCode with tests you suspect are not covering much.
- Fifteen edge cases, list onlyShortA function you are about to call finished.
- Five tests worth writingMediumA change you want covered without writing forty tests.
- Edge cases for this featureMediumBefore QA finds them for you, loudly.
Test strategy
Unit or integration, what to skip, fixture design, and pruning a suite that costs too much.
- Decide unit or integration for this codeLongWhen you are not sure whether to mock the boundary or cross it.
- Design test data for this featureLongWhen every test starts with forty lines of fixture setup.
- Audit a test suite for value versus noiseLongA suite that takes 20 minutes and nobody trusts the red runs.
- Decide what not to testLongWhen the test plan has grown beyond the time available.
- What should I not test?ShortA suite that costs more to maintain than it catches.
Reviewing existing tests
Judging naming, mocking, and whether a test asserts behaviour or just the implementation.
- Rename these tests so failures explain themselvesLongWhen a red CI run tells you `test_handler_2` failed and nothing more.
- Review my mocking strategyLongA test file with more setup than assertions.
- Would this catch a real bug?ShortA test you wrote mainly to make coverage go up.
- Name this test properlyShortA failure message that tells you nothing about what broke.
- Behaviour or implementation?ShortA test that breaks every time you refactor.
- One-line test descriptionShortA test whose intent is not obvious from its body.
- Review these testsMediumA suite you inherited and do not yet trust.
Failing and flaky tests
Diagnosing a red run, stabilising a flake, and locking a fixed bug in with a regression test.
- Make this flaky test deterministicLongA test that passes locally and fails in CI roughly one run in ten.
- Write a regression test from a bug reportLongA bug is fixed and you want it to stay fixed.
- Diagnose why this test is failingLongA red test where the failure output does not point anywhere obvious.
- Why is this flaky?ShortA test that fails once every twenty runs.
- Write the failing case firstShortA bug you are about to fix.
- Regression test from this bugMediumA bug you have just fixed and never want back.
- Diagnose this failing testMediumA red test with an unhelpful failure output.
Beyond unit tests
Manual QA, exploratory charters, accessibility, load, and contracts between services.
- Write exploratory testing chartersLongAn hour of manual testing on a new feature, and you want it structured.
- Accessibility test pass on a featureLongBefore shipping any interface, not after someone files a complaint.
- Design performance test scenariosLongBefore a launch where load is a real unknown.
- Define contract tests between two servicesLongTwo services that integrate fine in staging and break on deploy day.
- Write a manual QA script someone else can runLongHanding regression testing to a person who did not build the feature.
- Convert a manual test to an automated oneLongA manual check that has been run by hand thirty times.
- What breaks at scale?ShortCode written against a small, friendly test fixture.
- Manual QA scriptMediumHanding testing to someone who did not build the thing.
Got one that isn't here?
Send a prompt you keep coming back to. A person reads every one.
Suggest a prompt