Prompt engineering for QA: the RICEPOT framework

Prompts are level zero. The path runs prompts, then skills, then agents, then orchestration, and skipping ahead does not work: an agent built by someone who cannot write a prompt is an agent that produces garbage faster.

There are three ways to get more out of a large language model. Prompt engineering is the first and the one that pays immediately. RAG (retrieval augmented generation) is the second. Fine-tuning the model is the third. This session is entirely about the first.

The single sentence to take away: never ask the LLM, always tell it.

Asking gets you roughly 20 percent of what the model can do. Telling gets you around 80 percent. Asking is "give me a test plan". Telling is "give me a test plan, in this format, with these constraints".

The formal definition, and the word most people skip: prompting is providing specific instructions or input to an AI so that you obtain the desired result. If you never state the desired result, the model picks one for you.

Here is the difference in one pair of examples:

Weak:  Write a test case for the login page.

Strong: Write 5 functional test cases for the email and password login,
        covering valid credentials, invalid credentials, empty fields
        and SQL injection. Give the output in Jira format with steps
        to reproduce and expected results.

The weak version is not a prompt, it is a question.

The four core rules

1. Be specific. How many, which fields, which scenarios, which format.
2. Provide context. Do not say "test the API". Give the endpoint and the documentation.
3. Define the output. Jira format, a table, specific columns. Say it, or the model invents one.
4. Set constraints. The boundary: "use only the PRD provided, if it is not in the PRD do not invent it".

The process, in order:

1. Define the goal. What exactly do I need, what is the output, what does success look like?
2. Gather the context. The PRD or requirement, API docs, screenshots, error logs, previous test cases, constraints, compliance documents.
3. Choose the prompting strategy. See below.
4. Structure the prompt. This is where RICEPOT comes in.
5. Add constraints. The do's, don'ts, mandatory and critical items.
6. Test and iterate. Nobody ships the first answer.
7. Document and reuse. Save the prompt as a file, because you will want it again next week.

The iterative pass is where coverage actually comes from. Asked once for login test cases and then pushed a second time, the model produced the forgotten forgot-password and remember-me cases.

Seven letters, in order. Anything the class builds for the rest of the course starts here.

Where it fits: RICEPOT is the general-purpose framework, described in class as the Brahmastra, the weapon that handles everything. It covers roughly 90 percent of cases and works well beyond testing: web and mobile applications, test plans, Selenium or Playwright frameworks, API automation, BDD, performance and security work.

The task: generate a Selenium framework for a Salesforce login page. The naive approach is one line, "create a Selenium script for this login page", and it fails. Here is the same task through RICEPOT, section by section, as written in the class file.

Role

You are an automation tester with 15 years of experience. You have a strong
understanding of CRM projects such as Salesforce. You need to create an
enterprise-level framework with Selenium, Java, Maven and TestNG, from scratch.

Instructions

Generate complete Selenium automation scripts following enterprise-level standards.
Automate and verify the results, and ensure the UI is thoroughly tested with valid
and invalid cases.

[CRITICAL] Apply @Test and the other necessary annotations. Include setup and
teardown. Implement robust exception handling. Use the Page Object pattern.
Use try-catch and explicit waits.

[MANDATORY] Use Page Object Model with Page Factory.
Do not use CSS selectors, use XPath only.
Do not use Thread.sleep, use WebDriverWait.
Output only runnable code: no explanations, no comments.
Generate exactly two scripts: one valid login, one invalid login.
Maintain a consistent structure and modularity across the generated scripts.

Context, Example, Parameters, Output, Tonality

Context:    a login script with a full framework for the Salesforce login page,
            covering the valid and invalid flows.
Example:    (a sample class from the previous framework, pasted in full)
Parameters: production-level scripts with near-zero bad practice. Staging URLs
            supplied externally. Username and password supplied externally.
Output:     one page object file, two test scripts, a full enterprise-level Maven
            project. No explanation, no additional content.
Tonality:   technical, precise, enterprise-grade.

Two mechanics worth copying:

• Square-bracket tags like [CRITICAL] and [MANDATORY] mark the non-negotiable parts so they are not treated as suggestions.
• Negative instructions are repeated. "No comments" and "no CSS selectors" appear more than once, deliberately, because comments and explanations are also tokens you pay for.

What came back: exactly the planned files, with try-catch and explicit waits, no stray comments, in one pass. Before writing anything, the agent asked three clarifying questions: where to create the project, whether Salesforce credentials were available, and whether a screenshot or DOM of the login page could be provided.

The workflow that makes the above work:

1. Start in plan mode with the RICEPOT prompt: "using this prompt, tell me what you understand and create a plan."
2. Read the plan. It names the exact files that will be created.
3. Only then switch to agent mode and let it build.

Ninety-five percent of the work is planning, five percent is execution. That ratio is the reverse of how most people work with these tools.

The token objection came up in class and deserves the honest answer: yes, a long prompt costs more tokens than a short one. But:

• Planning is cheap. The input is a markdown file and the output is a markdown plan. You are not billed for thinking, you are billed for tokens in and tokens out.
• Execution is expensive, and planning is what keeps execution small. Without a plan the agent might create ten files. With one, it created three, because the plan said three.
• If the plan proposes files you do not want, you delete them in the plan, before a single token is spent generating them.

There is no industry standard for prompt frameworks. The class reviewed more than twenty and settled on RICEPOT, but smaller ones fit smaller jobs:

Also named in passing: CRAFT, DETAIL, the prompt sandwich, and ReAct. Expansions vary between sources, which is exactly the point about there being no standard.

A CRAP example in one line: "You are a QA mentor with 15 years of experience. Help me design a test plan for app.vwo.com. Include objective, scope, test plan and approvals."

The template library

Around 40 ready-to-use QA prompt templates are being shared, built on RTCFR, the short form of RICEPOT: Role, Task, Constraint, Format, Requirement. The requirement section is where your context goes.

The set covers: a basic test case generator, a PRD-based generator covering functional, negative, boundary and edge cases, API test case generation, negative-only test cases, security cases around the OWASP Top 10, regression suites, bug reports from evidence, bug classification and triage, bug analysis, notes-to-bug-report conversion, and an API group covering validation, authentication, contract testing, performance scenarios and error handling.

Two rules for using them:

• Always stack the anti-hallucination rule on top. Treat the model as something that will confidently invent things; that rule keeps it grounded or makes it admit when it is unsure.
• Keep them in a templates folder in your repository, modified for your company, shared with your team. Then anyone can say "use template three for security auth" and get a consistent result.

• Does a long prompt burn more tokens? Yes. Ask whether you care more about tokens or about the task being done properly, and remember that planning reduces total spend.
• Can RICEPOT be combined with the anti-hallucination rule? Yes. Keep both as markdown files and mix them.
• Is there an official standard or website for these frameworks? No. Different vendors teach different letters. The concepts are the same.
• Does RICEPOT only work for QA? No. Any goal with a role, an instruction and a desired output, down to planning a trip.
• How do I push my work to GitHub? Create a repository at github.com/new, copy the link, and tell the agent to commit and push to it. When it asks for credentials, use your email and a personal access token from Settings, Developer settings, Personal access tokens, classic, with the repo scope selected.
• Can I do this on my office laptop? Avoid pushing office code to a personal repository, and get approval first.
• How do I get a Jira token at work? Ask IT, or generate a read-only token from the Atlassian token page after authenticating with your company account.
• The free tiers run out quickly. They do. Paid tiers are cheap relative to the time saved, and nothing is truly free: free tools are often paid for with your data.

• Today's task: create a test plan and test cases for app.vwo.com using RICEPOT. The prompt itself should be a full page, with do's, don'ts and mandatory items spelled out, for the login page.
• Playwright batch, additionally: build an advanced Playwright framework for the same login page, again driven by a RICEPOT prompt.
• Keep every template as a markdown file in a templates folder. Next week they become skill files.
• Tomorrow: the BLAST framework, which is how you avoid AI slop, meaning low-quality generated noise you do not understand.
• Claude 101 part two: Tuesday evening, including the exam and certification. The part-one recording is being shared for anyone who missed it.
• Coming later: Codex and Cursor masterclasses. The Claude Code masterclass is already recorded.
• Post questions in SDET Club, not the Zoom chat, so the answer stays visible for everyone else. Zoom questions get lost.
• The templates and today's repository code are being shared.
• If the practice platform misbehaves in Chrome, use Firefox for now; a chunking issue is being fixed.
• Optional reading: learnprompting.org, and the introductory prompt engineering course mentioned in class.