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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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:
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.
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.