AI for testers: test cases, checklists and bug reports

A tester spends a noticeable share of the day on text: reading requirements, writing test cases, filing bugs. Models handle text well, with one caveat: they confidently fill in what the requirements do not say. Below we look at how to use AI for testers so that it speeds up routine work while you still guarantee the completeness of the checks.

All examples go through an OpenAI-compatible API at https://api.zukko.pro/v1 with a fetch_... key. The model and prompts can be dropped into any client, and at the end there is a script for batch processing.

What to hand to the model and what to keep

The model is good at enumerating and formatting. The decision about what matters in your system stays with a person.

Test cases from requirements

The main trick is to confine the model to the requirement text and ask it to mark assumptions explicitly.

The "Requirement clause reference" column exists for control: a case with no reference is either invented or refers to undescribed behavior, and should be reviewed separately. The "Questions" section turns into a list of clarifications for the analyst, a useful side effect.

If the project has screenshots of mockups you can attach them to the request: models marked "image input: yes" in the table (for example claude-sonnet-5-5, gpt-6.1-sol) accept images. This is covered separately in Screenshot analysis for QA↗.

How to check coverage

The weakest point of case generation is missed branches. Three ways to check:

1. Reverse traceability. In a separate request ask the model to extract every testable statement from the requirement, number them, and then map them to case IDs. Statements with no cases are gaps.
2. Test design techniques. Explicitly request equivalence classes and boundary values for each input field, then compare with the cases.
3. A second "find the gaps" pass. Give the requirement and the finished set of cases and ask which scenarios are not covered: external service failures, simultaneous actions, access rights, form resubmission. The answer is not the truth, it is a hint for your own review.

It is good practice to run generation and checking as separate requests, and optionally on different models: that gives the check a better chance of catching what generation missed.

Checklists and bug reports

A release or feature checklist comes together quickly if you give the model context: product type, platforms, what changed. Ask it to group items by priority and mark those that can be automated.

For bug reports, give raw notes and a template:

The "do not add" line matters: without it the model will happily invent a browser version or a reproduction step. The model only suggests severity; the decision is yours.

Code analysis and automated tests

If you write automated tests, the model can help with code too. Pass a function or a diff and ask which behaviors are worth checking: condition branches, empty value handling, exceptions. For automated code checks in a pipeline there is a separate walkthrough, AI code review↗, and test generation by an agent in a repository is covered in Generating tests in Claude Code↗.

Always run and read generated automated tests: a test that always passes is worse than no test.

A script for batch processing

A minimal example: a file with the requirement goes in, a table of cases comes out.

import sys
from openai import OpenAI

client = OpenAI(base_url="https://api.zukko.pro/v1", api_key="fetch_...")

PROMPT = open("prompt_testcases.txt", encoding="utf-8").read()

def make_cases(requirement: str) -> str:
    resp = client.chat.completions.create(
        model="claude-sonnet-5-5",
        messages=[
            {"role": "system", "content": PROMPT},
            {"role": "user", "content": requirement},
        ],
    )
    print("tokens:", resp.usage.prompt_tokens, resp.usage.completion_tokens, file=sys.stderr)
    return resp.choices[0].message.content

if __name__ == "__main__":
    text = open(sys.argv[1], encoding="utf-8").read()
    print(make_cases(text))

Run it as python make_cases.py requirement.md > cases.md. For regular use it makes sense to keep the prompt in a file and version it with the project.

What it costs

Assume (illustrative volumes) a requirement of 2000 tokens and a reply with a table of cases of 3000 tokens. Prices as of October 18, 2026, $ per 1M tokens:

Fifty such requirements come to about $0.34 on claude-sonnet-5-5 and $0.007 on deepseek-v4.1-flash. Which model will handle your requirements better is something neither the price table nor the strength index can tell you: take three real requirements and compare the results by eye. Check current prices in GET https://api.zukko.pro/v1/models.

What not to hand to a model

• Real personal data of users and the contents of production databases. For test data use synthetic sets, see Generating test data↗.
• Closed source code and requirements that your company policy forbids sending to third parties. Check the policy before you start.

To try it, create a key in the dashboard, put it into the script and run one of your own requirements.

FAQ

Will AI replace the tester?

No. It speeds up drafting, but identifying risks, understanding the product context and making the "ship or not" call still belong to a person. The model does not know how the system actually behaves.

Which model should I pick for checking code?

Start with an inexpensive model and test it on your own code: each has its own strengths, and nothing can be claimed in advance. Look at price, context size and the result on your examples.

How do I avoid made-up test cases?

Confine the model to the requirement text, demand a clause reference for every case and ask it to put missing information in a separate list of questions. Review cases without a reference by hand.

Can I generate cases from a mockup screenshot?

Yes, if you pick a model with image input. State in the request what exactly to check and verify the result against the mockup: the model sometimes reads interface details inaccurately.