Prompt Engineering for Manual Testers: How to Get Useful Output from AI Tools

You opened the AI assistant for the first time with a fair amount of hope. You typed "write test cases for the login page." You got eight test cases back in about three seconds. Valid login. Invalid password. Empty username. Empty password. The kind of list you could have written in your sleep, missing every scenario that actually matters for your product. So you closed the tool and thought: this is fine for the basics, but it does not really get testing.

AI is overhated. Here is the reframe that matters. The AI did not fail you. Your prompt did. "Write test cases for the login page" is not a testing brief. It is a shrug. You handed a capable assistant almost nothing to work with, and it gave you the most average answer the internet could produce. A generic prompt gets a generic answer. A tester's prompt gets a tester's answer. That gap, between the lazy request and the precise one, is prompt engineering. It is not coding, and it is not magic. It is the skill of telling an AI exactly what you need in a way that gets you something worth keeping.

This guide is a practical, non-technical walkthrough for manual testers: why vague prompts produce useless output, the anatomy of a prompt that works, before-and-after examples for the jobs you actually do every day, and why this is becoming a skill worth putting on your resume. No code. Just words, used well.

The Short Answer

How to get useful output from AI when testing, at a glance:

• Give it a role: tell it who to be, a senior QA tester for your kind of product.
• Give it context only you have: the product rules, edge cases, and known issues an AI cannot see.
• Name the risk you care about: point it at negative and edge cases, not happy paths.
• Specify the format: a table, Given/When/Then, or your bug template.
• Treat it as a conversation: correct the first draft instead of accepting it.

The rest of this guide breaks down each of these, with prompts you can paste in this afternoon.

Why "Write Test Cases for the Login Page" Gets You Nothing Useful

An AI model is built to give you the most probable answer. When your prompt is vague, the most probable answer is the most generic one, an average of every login test ever written, with nothing specific to your product in it. That is the whole problem in one sentence.

The model does not know your application. It does not know that your login locks after five attempts, that you support biometric sign-in, that there is a known bug around expired sessions, or that your users are stressed people checking a bank balance on a train with one bar of signal. It cannot see any of that. So when you leave it out, the AI fills the gap with the blandest possible guess.

You, on the other hand, know all of it. That knowledge is the entire value you bring. Prompt engineering is just the act of moving what is in your head into the prompt, so the AI has something real to work with. The quality of what you get out is set by the quality of what you put in.

This is not a Katalon opinion. It is now baked into the testing profession's own standards. In 2024 the ISTQB introduced a separate specialist certification, Certified Tester Testing with Generative AI (CT-GenAI), and its syllabus includes a dedicated section on prompt engineering alongside large language models and risk management. When the body that writes the rules for software testing creates a certification partly about how to prompt, that is a clear signal: this is a real, recognized skill, not a party trick.

The Anatomy of a Prompt That Actually Works

A good testing prompt is not longer for the sake of it. It is just complete. Five pieces turn a shrug into a brief, and you can remember them as Role, Context, Task, Focus, and Format.

You do not need all five every time, but Context and Focus are the two that separate a tester's prompt from everyone else's. Context is the product knowledge the AI cannot have. Focus is your judgment about where the bugs hide. Those are exactly the things a generic user would never think to include, which is why a tester who prompts well gets dramatically better output than someone who does not.

Generic vs. Useful: The Same Request, Two Ways

The fastest way to feel the difference is to see it. Here is the same job, prompted two ways.

Weak prompt:
"Write test cases for the login page."

Strong prompt:
"Act as a senior QA tester for a mobile banking app. Login uses email and password, locks after 5 failed attempts, supports Face ID, times out after 10 minutes idle. Return a table: Test Case, Preconditions, Steps, Expected Result. Focus on negative and edge cases: locked accounts, expired sessions, Face ID failure and fallback, a user already logged in elsewhere. Aim for 12-15 cases."

Result (weak): 4 happy-path lines anyone could have written.
Result (strong): a focused suite aimed at what actually breaks in production.

The weak prompt gets you four happy-path lines. The strong one gets you a focused suite aimed at the scenarios that actually break in production, because you told it where to look. Same tool. Same three seconds. Completely different value.

Notice that nothing in the strong prompt is technical. There is no code, no syntax, no special command. It is just a tester describing the feature and the risk the way you would brief a new colleague joining your team. If you can explain a feature to a junior tester, you can write a strong prompt.

Four Prompt Engineering Examples for the Jobs You Do Every Day

Theory is fine, but you came here for things you can paste into a tool this afternoon. Here are four recipes for the work manual testers do constantly. Adapt the bracketed parts to your product.

Generate a test case worth keeping

The trick is to feed the requirement and then constrain the output toward depth instead of volume.

"Here is a requirement: [paste the user story or acceptance criteria]. Act as an experienced tester. Generate test cases that cover the main flow, the alternate flows, and the failure paths. For each case give Preconditions, Steps, and Expected Result. Do not include trivial cases that would pass even if the feature were broken."

That last sentence matters. It pushes the AI away from filler like "verify the page loads" and toward cases that would actually catch a defect.

Make AI find the edge cases you might miss

Use the AI as a brainstorming partner whose only job is to widen your thinking, not to write the final cases.

"For this feature: [paste description]. List 10 edge cases and boundary conditions that a typical test plan would overlook. Think about empty states, maximum lengths, special characters, slow or dropped network, concurrent users, and time zones. For each one, add a single line explaining why it is risky."

You will keep maybe six of the ten and roll your eyes at the rest. That is a good outcome. Six edge cases you had not written down yet, in thirty seconds, is real coverage you would otherwise have missed.

Generate negative and unhappy-path scenarios

AI defaults to happy paths, so ask for the opposite explicitly.

"For the password reset flow described above, generate negative test scenarios only. Include invalid and malformed inputs, an expired reset link, a reset link used twice, a mismatched confirmation field, and abuse cases such as requesting 50 resets in a minute. Format each as Given / When / Then."

Naming the categories you want ("expired link," "reused link," "abuse cases") is what gets you scenarios with teeth instead of three variations on "enter a wrong password."

Turn a messy session note into a clean bug report

This is the one that wins people over, because it removes a chore you actively dislike. Paste your rough note and let the AI do the formatting, with one important guardrail.

"Turn this rough session note into a clear bug report: 'tried to upload a 12MB profile photo, spinner just span forever, refreshed and my old photo was gone too, happened twice.' Use this format: Title, Environment, Steps to Rep