This is the foundation everything else in the course is built on. If you can write a strong prompt, every AI tool you touch becomes dramatically more useful. If your prompts are vague, no tool will save you. The good news: prompting is a learnable structure, not a talent, and once you see it you will never go back to typing vague requests and hoping for the best.
A great prompt has five components
You do not always need all five, but the more you include, the better your output. Think of them as layers that build on each other.
- Role: tell the AI who it is. For QA that is usually a Senior QA Engineer, an SDET, or a Test Architect. The role sets vocabulary, depth, and approach.
- Context: the feature under test, the tech stack, constraints, and the business logic that matters.
- Task: exactly what you want produced. "Help me with testing" is not a task. "Generate 10 test cases" is.
- Constraints: what to include, what to exclude, and the boundaries to work within.
- Format: exactly how the output should be structured. This is the component most people skip, and it costs them the most time in reformatting.
Role and context set the stage
Weak prompt, no role: "Write test cases for a login page." Strong prompt: "You are a Senior QA Automation Engineer with 8 years of experience in web application testing." When you assign a role, the AI thinks about edge cases and regression risk instead of listing the obvious.
Context does the same for relevance. Instead of "Write test cases for user registration," give the AI the field rules, the validation model, and the business logic:
- Full name (required, 2 to 50 characters)
- Email (required, must be unique in the system)
- Password (min 8 chars, 1 uppercase, 1 number)
- Validation runs client-side and server-side
- After registration, users get a verification email and cannot log in until verified
The rich version produces test cases that match your application. The bare version forces the AI to guess, and its guesses are generic.
Task, constraints, and format make it usable
Be specific about the deliverable. A strong task says how many and how to distribute: "Generate 12 test cases: 4 happy path, 4 negative/validation, 4 edge cases (boundary values, encoding)." That distribution stops the AI from handing you 10 happy paths and nothing else.
Constraints narrow the output from "everything possible" to "exactly what I need":
- Focus on server-side validation only
- Do not include UI/visual test cases
- Use Playwright with TypeScript syntax
- Keep test cases independent (no dependencies)
- Priority should reflect real-world risk
Format makes it ready to paste straight into your test management tool or Jira ticket. Spell out the columns, the ID convention (TC-CHECKOUT-001), and the allowed values for Priority and Type. Specify the format and the AI delivers output you do not have to reshape.
Putting all five together
A complete prompt that uses every component runs about 20 lines and takes roughly 60 seconds to write: role (Senior QA Engineer for e-commerce), context (a shopping cart with quantities 1 to 99, one discount code per order, real-time tax, local-storage persistence), task (15 test cases split 5 happy, 5 negative, 5 edge), constraints (functionality not appearance, at least 2 discount-code cases, cover the empty cart), and format (a table with ID, Title, Steps, Expected Result, Priority, Type).
That 60 seconds produces 15 test cases specific to your app, formatted exactly how you need them. Compare it to typing "write shopping cart test cases" and spending 20 minutes editing generic output into something you can use. The time you spend up front is always paid back at the other end.
Iterate in two or three follow-ups, not from scratch
Even a strong prompt rarely lands perfectly on the first try. That is expected. The skill is refining in a couple of follow-ups instead of starting over. The five patterns you will reach for most:
- Add depth: "Expand TC-CART-003 with more detailed steps and the exact API calls that fire when the discount is applied."
- Shift focus: "These lean too hard on the UI. Rewrite them to focus on backend validation, what the API returns, not what the user sees."
- Change format: "Reformat as a markdown table with ID, Title, Steps, Expected, Priority. Keep the same test cases."
- Expand coverage: "Add 3 edge cases for concurrent cart updates and 2 for expired sessions. Same format."
- Simplify: "Condense each to a one-line title, 3 steps max, and a one-sentence expected result so they fit in Jira."
If you are on iteration 5 or 6 and still off, the problem is the original prompt, not the follow-ups. Rewrite the initial prompt with more context and start fresh.
Patterns that work especially well for QA
Mix and match these with any prompt:
- Example pattern: show one test case in the exact format you want, then ask for nine more like it. The AI is excellent at pattern matching, so a concrete example beats describing the format in words.
- Persona swap: ask the AI to review its own output as a security engineer, a performance engineer, and a new user, adding 2 cases per perspective. This catches gaps a single viewpoint misses.
- Negative constraint: tell it what NOT to do ("Do NOT include UI scenarios, do NOT assume the search index is current, do NOT generate more than 10 cases"). Surprisingly effective.
- Chain pattern: break a big task into a sequence. List the features that need coverage, then generate cases for one feature, then convert the best cases into Playwright scripts. Each step stays focused and produces better output.
The takeaway
Specific in, specific out. Role, Context, Task, Constraints, Format is the whole game: 60 seconds of structure up front saves 10 to 15 minutes of rework and turns every AI tool into a force multiplier. Build this habit now and it carries every module that follows, and every QA job you walk into.