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.

Enter fullscreen mode Exit fullscreen mode

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.

Piece What it does Example ROLE Tells the AI who to be, which sets the depth and tone. “Act as a senior QA tester for a mobile banking app” CONTEXT Gives it the product facts only you know. “Login uses email and password, locks after 5 failed attempts, and supports biometric sign-in” TASK States the one job you want done. “Generate test cases for this screen” FOCUS Points it at the risk you care about. “Prioritize negative and edge cases, especially locked accounts and expired sessions” FORMAT Defines how you want the output so it is usable. “Return a table: Test Case, Preconditions, Steps, Expected Result. Aim for 12 to 15 cases”

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 Strong prompt “Write test cases for the login page.” “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: 4 happy-path lines anyone could have written. Result: 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 Reproduce, Expected Result, Actual Result, Severity, Notes. If any detail is missing or ambiguous, list it under ‘Need to confirm’ rather than inventing it.”

That final instruction is the difference between a helpful draft and a dangerous one. Without it, the AI will happily invent a browser version, an exact file type, and a reproduction rate that you never observed. “Do not invent, ask me instead” keeps the output honest and keeps you in control of the facts.

Treat It Like a Conversation, Not a Vending Machine

The biggest mistake new users make is treating the AI like a vending machine: one prompt in, one answer out, take it or leave it. The testers who get real value treat it like a conversation.

When the first response is generic, do not give up and do not silently rewrite it yourself. Tell the AI what was wrong and let it try again. “These are all happy paths, give me the failure scenarios.” “Add cases for the biometric fallback.” “That bug title is vague, make it specific about the data loss.” Each correction is cheap, and the second answer is almost always far better than the first, because you have just given it the context you left out the first time.

Refinement is where your testing judgment does its real work. The AI drafts fast; you steer toward what is actually useful. That back-and-forth is the skill, and it is the part that gets better the more you understand good testing.

Common Mistakes When Prompting AI for Testing

• Asking for everything at once. “Test my whole application” gives the AI nowhere to focus and you a shallow, scattered answer. One feature, one clear task per prompt.
• Giving zero context. If you do not tell the AI about your product, its rules, and its users, it cannot account for them. Missing context is the number one cause of generic output.
• Accepting the first draft. The first answer is a starting point, not a deliverable. If you ship it untouched, you are not testing, you are forwarding.
• Letting it invent specifics. Left unchecked, AI will fabricate steps, data, versions, and reproduction rates that sound plausible and are simply made up. Always tell it to flag unknowns instead of filling them in, and verify what it gives you.
• Forgetting the format. A wall of prose you have to reformat by hand is barely a time save. Tell the AI exactly how you want the output, a table, Given/When/Then, your bug template, and it becomes usable immediately.
• Forgetting that you are still the reviewer. The AI proposes; you approve. A prompt that produces a confident, well-formatted, subtly wrong test case is more dangerous than no test case at all. Your eyes are the last gate, every time.

Why Prompting Is a Skill, Not a Shortcut

There is a quiet fear in manual testing right now: if AI can generate test cases, what is left for me? Prompt engineering is one of the clearest answers, because it flips the question. AI does not replace the tester who can prompt well. It multiplies them.

Look again at what every good prompt in this guide required. Knowing which risks matter for your product. Knowing where bugs actually hide. Knowing what a useful test case looks like versus a trivial one. Recognizing a generic answer and knowing how to push for a better one. Spotting an invented detail before it reaches a bug report. None of that comes from the AI. All of it comes from you. The prompt is just the pipe that carries your expertise into the tool, and a person without testing judgment writing prompts gets confident, fluent, useless results.

This is the bridge between “AI exists” and “I use AI in my daily work,” and crossing it is a deliberate, learnable skill rather than a personality trait. The profession has already recognized it: ISTQB built an entire specialist certification, CT-GenAI, around using generative AI in testing, with prompt engineering as a core topic. The tester who learns to drive these tools well is not being automated away. They are quietly becoming two or three times more productive than the colleague who typed “write test cases for the login page,” got junk, and gave up.

The testers who thrive will not be the ones who avoid AI or the ones who blindly trust it. They will be the ones who learned to ask it the right questions.

Putting This to Work in Katalon AI Assistant

Everything above is tool-agnostic. The same principles, role, context, task, focus, format, and refine through conversation, apply directly inside Katalon True Platform’s Katalon AI Assistant, which is built to be conversational rather than one-shot. Katalon has written about what the AI Assistant is and what it can do; this article is the companion that teaches you how to actually talk to it.

A few ways the assistant is designed around these habits:

• It works in one continuous conversation. You can refine a requirement, generate test cases, and tighten them in the same thread, which is exactly the iterative, vending-machine-is-the-wrong-model approach this guide argues for.
• It asks for context instead of guessing. When the Test Generation Agent needs more to produce good test cases, the assistant prompts you for the missing detail first, turning the “give it context” rule into part of the workflow rather than something you have to remember.
• It keeps you as the approver. Generated cases are drafts you review, edit, or discard, and each can trace back to its requirement. The model is consistent with everything here: AI proposes, you approve.

The platform handles speed and structure. You bring the judgment and the prompts. That division of labor is the whole point.

If you write test scripts as well as test cases, the same prompting discipline, role, context, and iteration, carries over to code generation. Katalon has a separate, more technical walkthrough of prompt engineering inside Katalon Studio’s StudioAssist for automation engineers who want AI to help write automation scripts rather than test cases.

Key Takeaways

• A vague prompt gets a generic answer because the AI fills the gaps with the most average response. The quality of the output is set by the quality of your input.
• The AI does not know your product, your risks, or your users. Prompt engineering is the act of moving that knowledge into the prompt.
• Use Role, Context, Task, Focus, and Format. Context and Focus are what make a tester’s prompt better than anyone else’s.
• For everyday jobs, constrain toward depth: ask for non-trivial test cases, overlooked edge cases, negative-only scenarios, and clean bug reports from rough notes.
• Always tell the AI to flag unknowns rather than invent them, and treat it as a conversation, correcting and refining instead of accepting the first draft.
• You are still the reviewer. AI proposes, you approve, every time.
• Prompting well is a recognized, high-value skill, ISTQB built the CT-GenAI certification around using generative AI in testing, with prompt engineering at its core. It multiplies good testers rather than replacing them.

The difference between “AI is overhyped” and “AI saves me hours every week” is usually just the prompt. Learn to brief these tools like you would brief a sharp new colleague, and they start earning their place in your daily work. Katalon AI Assistant is built for exactly this kind of back-and-forth, with you as the final word on quality. AI proposes, you approve.