Prompt engineering: a test-design skill

01Why prompting is a QA skill

Ask a model to "write test cases for this PRD" and you get plausible rows. Some of them test features the PRD never mentions, cite error codes nobody defined, and come back in a different format every run. A tester would reject that from a person. Chapter 2 makes the prompt specific enough that you can reject it from a model too.

The chapter has three pillars, and this page follows them:

1. Anti-hallucination rules (Anti_Hallucinations_Rules.md): the model may use only the inputs you give it, and must say so, in exact words, when something is missing.
2. RICE-POT: Role, Instructions, Context, Example, Parameters, Output, Tone. A structure that forces you to state persona, constraints and format.
3. Templates and two projects: six RTCFR templates for daily QA tasks, test cases generated from a PRD, and a Selenium framework generated from a prompt.

02RICE-POT, letter by letter

The worked prompt in Project1_TC_Gen/RICE-POT-TestCase-Prompt.md asks for functional and non-functional test cases for VWO (app.vwo.com). Each letter answers one question the model would otherwise guess.

flowchart LR
  G["Goal: what should the AI produce?"] --> R["R: persona"]
  G --> I["I: steps + Don't list"]
  G --> C["C: PRD / API doc"]
  G --> E["E: one sample row"]
  G --> P["P: anti-hallucination"]
  G --> O["O: format spec"]
  G --> T["T: output-only"]
  R --> A["Assemble the template"]
  I --> A
  C --> A
  E --> A
  P --> A
  O --> A
  T --> A
  A --> X["Copy-paste prompt"]
  X --> Y{"Run on an LLM"}
  Y --> Z["Refine: tighten the Don't list, dedupe columns"]
  Z --> A

03Live demo: build a RICE-POT prompt

The seven fields start with the repo's VWO prompt. Switch parts off and on, edit any field, and watch the assembled prompt, the checklist and the comparison change. The rule checks are the six strict rules of Anti_Hallucinations_Rules.md, matched as text in your prompt, with the part each one was found in.

04The anti-hallucination block

Anti_Hallucinations_Rules.md is a ROLE block you put above any QA prompt that generates facts. It limits the model to the inputs you provide, and it gives a gap an exact name.

ROLE: You are a QA assistant operating under strict verification rules.

## SCOPE OF KNOWLEDGE

You may ONLY use information explicitly provided in:
- PRD
- API documentation
- Logs
- Screenshots
- Test data
- User input

## STRICT RULES (MANDATORY)

1. DO NOT invent features, APIs, error codes, UI elements, or behavior.
2. DO NOT assume default or "typical" system behavior.
3. If information is missing or unclear, respond with:
   "Insufficient information to determine."
4. Every assertion must be traceable to provided input.
5. If a detail is inferred, label it explicitly as:
   "Inference (low confidence)".
6. Output must be deterministic and repeatable.

## PROCESS YOU MUST FOLLOW

**Step 1:** Extract verifiable facts from the input.

**Step 2:** List unknown or missing information.

**Step 3:** Generate output ONLY from Step 1 facts.

**Step 4:** Perform a self-check for hallucinations or contradictions.

## OUTPUT FORMAT (STRICT)

- Verified Facts:
- Missing / Unknown Information:
- Generated Output:
- Self-Validation Check:

---

**If you cannot complete a step, stop and report why.**

The two fallback strings are the part a tester should care most about. Insufficient information to determine. and Inference (low confidence) are greppable: a reviewer, or a script in a pipeline, can count them in the output instead of trusting fluent text. The same rules, shaped as a RICE-POT Parameters block:

## Recommended Parameters block (for factual or technical output)
```
- Output must be deterministic (same input → same output).
- Every assertion must be traceable to a provided input.
- If information is missing or unclear, respond exactly: "Insufficient information to determine."
- If a detail is inferred, label it exactly: "Inference (low confidence)".
- Do not invent features, IDs, APIs, error codes, UI elements, or behavior.
- Do not assume default or "typical" system behavior.
```

05Project 1: test cases from a PRD, then check them

The repo commits one real model output for the VWO prompt: output/deepseek_csv_20260524_0d9b7c.csv, a header and 11 login cases (TC-LOGIN-001 to 007, TC-SEC-001, TC-NAV-001, TC-ACC-001, TC-LOAD-001). Parse it before you trust it. Four rows break the 13-column contract because a field contains a comma and the field is not quoted:

Scenario, TID, Test Data, Test Case Description, Pre-Condition, Test Steps, Expected Result, Actual Result, Status, Executed By (QA Name), Misc (Comments), Priority, Is Automated
Login, TC-LOGIN-001, Valid email + valid password, Verify successful login with valid credentials (positive scenario), User account exists and is active, 1. Navigate to app.vwo.com 2. Enter valid registered email 3. Enter valid corresponding password 4. Click Login button, User is redirected to main VWO dashboard; session is established; user sees personalized dashboard, , , , , High, No
Login, TC-LOGIN-002, Invalid email format (e.g., "userexample.com"), Verify real-time email format validation triggers on blur (negative scenario), Login page loaded; JavaScript enabled, 1. Navigate to app.vwo.com 2. Click into email field 3. Type "userexample.com" 4. Tab or click out of email field (blur), Field shows email format validation error message; error is immediate and clear; specialized mobile keyboard not triggered (desktop context), , , , , High, No

The second artifact, Restful_Booker_API_Test_Cases.md, was generated from Restful-booker.pdf (the prompt and model are not recorded). It holds 65 cases in 9 groups (2, 7, 9, 8, 15, 8, 6, 8, 2), while its own summary says "87+". The PDF documents only 200 OK and 201 Created; the cases also assert 204, 400, 401, 403, 404, 405 and 415, often hedged as "403 Forbidden or 401 Unauthorized". Under the rules above, each of those should carry Inference (low confidence).

flowchart LR
  IN["PRD and screenshots, or an API PDF"] --> PR["RICE-POT prompt + Parameters block"]
  PR --> LLM["Any LLM"]
  LLM --> CSV["CSV only"]
  CSV --> REV{"QA review"}
  REV -->|"13 columns, 10+ rows, traceable"| TM["Import to the test tool"]
  REV -->|"broken rows, invented codes"| FIX["Tighten the prompt, or ask"]
  FIX --> PR

06Project 2: a Selenium framework from one prompt

Project 2 tests whether RICE-POT can produce code, not just test cases. The whole brief, from Problem.md:

We have to generate a Selenium automation framework from scratch where you need to add a two-page object model, proper production ready.

The output, AdvanceSeleniumFramework/, is a Maven project on Java 11 with Selenium 4.25.0 and TestNG 7.10.2 that tests the Salesforce login page in headless Chrome.

    public LoginPage(WebDriver driver) {
        this.driver = driver;
        this.wait = new WebDriverWait(driver,
                Duration.ofSeconds(ConfigReader.getInt("timeout.explicit")));
        PageFactory.initElements(driver, this);
    }

    public LoginPage enterUsername(String username) {
        try {
            wait.until(ExpectedConditions.visibilityOf(usernameField));
            usernameField.clear();
            usernameField.sendKeys(username);
        } catch (TimeoutException e) {
            throw new RuntimeException("Username field not visible within timeout", e);
        }
        return this;
    }

flowchart TD
  CFG["config.properties"] --> CR["ConfigReader"]
  CR --> BT["BaseTest"]
  BT -->|"@BeforeMethod"| D["ChromeDriver, headless"]
  BT -->|"@AfterMethod"| Q["driver.quit()"]
  VT["ValidLoginTest"] --> LP["LoginPage: PageFactory, XPath only"]
  IT["InvalidLoginTest + @DataProvider"] --> LP
  VT -.->|extends| BT
  IT -.->|extends| BT
  SUITE["testng.xml"] --> VT
  SUITE --> IT
  SMOKE["testng-smoke.xml"] --> IT

# JDK 11+ and Maven 3.9+
cd chapter_02_Prompt_Eng/Project2_Selenium_Framework/AdvanceSeleniumFramework
mvn -q clean test-compile
mvn test                       # runs testng.xml, the suite pom.xml names

07Six RTCFR templates

The templates/ folder holds six copy-paste prompts for the QA tasks that come up every week. They follow RTCFR (Role, Task, Constraints, Format, Requirements), the lightweight cousin of RICE-POT. All six are in the Solution tab, verbatim.

1. Open the file and copy the prompt block.
2. Replace [FEATURE], [PASTE REQUIREMENTS], [PASTE PRD HERE] and the like with your input.
3. Paste it into any AI tool. Keep the CONSTRAINTS block intact: that is what stops invention.

08What to watch

• The worked prompt targets VWO. The README suggests attaching Restful-booker.pdf; if you do, rewrite C (and the product in I) first, or the model is told to test one product from another product's document.
• CSV is a contract, so parse it. Unquoted commas shift columns. Adding "wrap every field in double quotes" to O is a cheap fix to try.
• A model's count of its own output is not a count. 65 cases, "87+" claimed. Count rows yourself.
• Traceability needs a column. Instruction 5 asks to trace every case, but the 13 columns have nowhere to put the reference, so nothing in the file can be checked against the PRD.
• Check every status code and message against the source. Anything the document does not state is an inference, and the rules say to label it.
• Match the tone to the output. SKILL.md's guardrail: "code-only" suits code, not a CSV; ask for "output-only, no commentary".
• Two files the skill points to are missing. SKILL.md refers to references/worked-example.md and references/blank-template.md; the blank template is blank-template-rice-pot.md next to it, and there is no worked example.
• The README's sample CSV row is illustrative. The TC_API_007 row it shows is not in the committed output.

DDrills for the chapter

Drills 1 to 6 use the files in chapter_02_Prompt_Eng. Drills 7 to 9 automate the prompt builder on this page: every control has a data-testid (turn on Show locator badges to see them).

1. Find the broken rows

   Load output/deepseek_csv_20260524_0d9b7c.csv with a CSV parser (Python's csv module, or a spreadsheet import) and count the fields in every row. Which rows do not have 13?

   Expected result

   TC-LOGIN-002 (14), TC-SEC-001 (15), TC-ACC-001 (19) and TC-LOAD-001 (15). Each has a comma inside an unquoted field.
2. Count the cases yourself

   Count the ### TC_ headings in Restful_Booker_API_Test_Cases.md and compare with the Summary at the end of the file.

   Hint

   grep -c "^### TC_" Restful_Booker_API_Test_Cases.md
   Expected result

   65. The Summary says "87+ comprehensive test cases", although its own per-group numbers (2, 7, 9, 8, 15, 8, 6, 8, 2) add up to 65.
3. Find the invented status codes

   List the HTTP status codes the Restful-booker cases expect that Restful-booker.pdf does not document.

   Expected result

   204, 400, 401, 403, 404, 405 and 415. The PDF documents only 200 OK and 201 Created. Under the anti-hallucination rules each should be marked Inference (low confidence), or the case should ask for clarification.
4. Upgrade an RTCFR template

   Rewrite templates/01_TestCaseGeneration_Prompt.md as a RICE-POT prompt for a feature you test.

   Expected result

   Keep the Role and Task (as R and I), then add what RTCFR lacks: Context (product and attached inputs), one Example row, the Parameters block with both fallback strings, an exact Output spec with columns in order, and a Tone line such as "output-only, no commentary".
5. Check the brief against the output

   Compare Problem.md with the files in AdvanceSeleniumFramework/. Was every requirement met?

   Expected result

   No. The brief asks for a two-page object model; there is one page object, LoginPage.java. A generated framework needs the same requirement review as a hand-written one.
6. Predict the first run

   Without editing config.properties, what should mvn test do? Reason from ValidLoginTest.java and InvalidLoginTest.java (this was not run for the page).

   Expected result

   loadCredentials() sees the REPLACE_WITH placeholders and throws in @BeforeTest, so TestNG skips the ValidLoginFlow tests as a configuration failure. InvalidLoginFlow still runs against the live login page, so it needs network access.
7. Score the repo promptPlaywright

   Write a Playwright test that loads this page and asserts the scores for the repo prompt and for the one-line prompt.

   Hint

   Locators: pe-parts-score, pe-rules-score, pe-one-parts, pe-one-rules, pe-one-guess.
   Expected result

   Repo prompt: 7 / 7 parts and 6 / 6 rules. One-line prompt: 1 / 7 and 0 / 6, with 6 items left for the model to guess.
8. Drop the ParametersPlaywright

   Switch P off, assert what was lost, then restore the rules with the recommended block.

   Hint

   Toggle: pe-toggle-p (watch aria-pressed). Rule rows: pe-check-rule-fallback, pe-check-rule-inference, pe-check-rule-deterministic, each with data-state. Restore: pe-params.
   Expected result

   Rules drop to 3 / 6: the fallback string, the inference label and determinism were only in P. "Do not invent", "typical" and traceability survive because I and R also state them. The recommended block brings it back to 6 / 6.
9. Write your own RolePlaywright

   Fill the R field with your own persona, then empty the E field. Assert the prompt and the checklist.

   Hint

   The R field has the label R - Role; E is pe-field-e; the part chip is pe-check-part-e.
   Expected result

   Your text appears in pe-assembled; parts drop to 6 / 7; pe-check-part-e has data-state="fail"; and pe-guess lists "what one good row looks like".

SSolutions: the demo test and the reusable prompts

The Playwright spec for the prompt builder, then the reusable prompts from the repo, verbatim: the anti-hallucination block, the six RTCFR templates and the recommended Parameters block.

import { test, expect } from '@playwright/test';

const URL = 'https://app.thetestingacademy.com/ai/blueprint/learn/prompt-engineering.html';

test('the repo prompt carries all seven parts and all six rules', async ({ page }) => {
  await page.goto(URL);
  await expect(page.getByTestId('pe-parts-score')).toHaveText('7 / 7');
  await expect(page.getByTestId('pe-rules-score')).toHaveText('6 / 6');
  await expect(page.getByTestId('pe-assembled')).toContainText('Insufficient information to determine.');

  // the one-line prompt is scored by the same checks
  await expect(page.getByTestId('pe-one-parts')).toHaveText('1 / 7');
  await expect(page.getByTestId('pe-one-rules')).toHaveText('0 / 6');
  await expect(page.getByTestId('pe-one-guess').getByRole('listitem')).toHaveCount(6);
});

test('dropping Parameters loses three anti-hallucination rules', async ({ page }) => {
  await page.goto(URL);
  await page.getByTestId('pe-toggle-p').click();
  await expect(page.getByTestId('pe-toggle-p')).toHaveAttribute('aria-pressed', 'false');
  await expect(page.getByTestId('pe-rules-score')).toHaveText('3 / 6');
  await expect(page.getByTestId('pe-check-rule-fallback')).toHaveAttribute('data-state', 'fail');
  await expect(page.getByTestId('pe-assembled')).not.toContainText('Insufficient information');

  await page.getByTestId('pe-params').click();
  await expect(page.getByTestId('pe-rules-score')).toHaveText('6 / 6');
  await expect(page.getByTestId('pe-check-rule-fallback')).toHaveAttribute('data-state', 'pass');
});

test('your own text lands in the prompt and the checklist follows', async ({ page }) => {
  await page.goto(URL);
  await page.getByLabel('R - Role', { exact: true }).fill('You are a senior API tester.');
  await expect(page.getByTestId('pe-assembled')).toContainText('You are a senior API tester.');

  await page.getByTestId('pe-field-e').fill('');
  await expect(page.getByTestId('pe-parts-score')).toHaveText('6 / 7');
  await expect(page.getByTestId('pe-check-part-e')).toHaveAttribute('data-state', 'fail');
  await expect(page.getByTestId('pe-guess')).toContainText('what one good row looks like');
});

ROLE: You are a QA assistant operating under strict verification rules.

## SCOPE OF KNOWLEDGE

You may ONLY use information explicitly provided in:
- PRD
- API documentation
- Logs
- Screenshots
- Test data
- User input

## STRICT RULES (MANDATORY)

1. DO NOT invent features, APIs, error codes, UI elements, or behavior.
2. DO NOT assume default or "typical" system behavior.
3. If information is missing or unclear, respond with:
   "Insufficient information to determine."
4. Every assertion must be traceable to provided input.
5. If a detail is inferred, label it explicitly as:
   "Inference (low confidence)".
6. Output must be deterministic and repeatable.

## PROCESS YOU MUST FOLLOW

**Step 1:** Extract verifiable facts from the input.

**Step 2:** List unknown or missing information.

**Step 3:** Generate output ONLY from Step 1 facts.

**Step 4:** Perform a self-check for hallucinations or contradictions.

## OUTPUT FORMAT (STRICT)

- Verified Facts:
- Missing / Unknown Information:
- Generated Output:
- Self-Validation Check:

---

**If you cannot complete a step, stop and report why.**

## Template 1: Basic Test Case Generation ( RTCFR) 
ROLE - You are a Senior QA Engineer.

TASK - Generate [NUMBER] test cases for [FEATURE].

 number is your educated guess 

CONSTRAINTS

- Use ONLY the provided requirements
- Do NOT assume undocumented behavior
- If information is missing, state "Not specified"


FORMAT:
| Test ID | Description | Pre-conditions | Steps | Expected Result | Priority |



REQUIREMENTS:
[PASTE REQUIREMENTS HERE]

## Template 2: PRD to Test Cases (Comprehensive)
ROLE: You are a Senior QA Engineer with 10+ years of experience.

TASK: Generate comprehensive test cases from this PRD.

COVERAGE AREAS:

- Functional (happy path)
- Negative scenarios
- Boundary values
- Edge cases
CONSTRAINTS:

- Use ONLY PRD content
- No assumptions about unmentioned features
- Mark unclear items as "Needs clarification"
- Do NOT invent error messages or codes
FORMAT:
| TID | Category | Description | Pre-conditions | Steps | Expected | Priority |



PRD / SRS / REQ / BRD / DRD / JIRA ID / confluece page(content) / HLD :
<<< [PASTE PRD HERE] >>

## Template 3: API Test Case Generation
```
ROLE: You are an API Testing Specialist.

TASK: Generate test cases for this API endpoint.

COVERAGE:
- Happy path (valid requests) | functionality
- Invalid inputs (validation errors)
- Authentication/Authorization
- Error handling
- Boundary conditions

CONSTRAINTS:
- Use ONLY the API documentation provided
- Include exact status codes from docs
- Do NOT assume undocumented behavior

FORMAT:
| Test ID | Endpoint | Method | Request Body | Expected Status | Expected Response |

API DOCUMENTATION:
<<<
[PASTE API DOCS HERE] - [documenter.getpostman.com/view/3967924/RW1dExDv](https://documenter.getpostman.com/view/3967924/RW1dExDv)
>>>
```

## Template 4: Negative Test Cases Only
```
ROLE: You are a QA Engineer focused on negative testing.

TASK: Generate negative test cases for [FEATURE].

FOCUS AREAS:
- Invalid inputs
- Boundary violations
- Missing required fields
- Unauthorized access
- Malformed data

CONSTRAINTS:
- Do NOT include happy path scenarios
- Each test must validate error handling
- Include expected error message if documented

FORMAT:
| Test ID | Invalid Scenario | Input | Expected Error |

FEATURE REQUIREMENTS:
[PASTE REQUIREMENTS] |. does not matter what you have here. You can mention Jira ID, SRS, BRD, PRD, Sprint Ticket, Jira ID, Test
```

## Template 5: Security Test Cases
```
ROLE: You are a Security QA Specialist.

TASK: Generate security-focused test cases for [FEATURE].

SECURITY AREAS:
- Input validation (SQL injection, XSS)
- Authentication bypass attempts
- Authorization checks
- Session management
- Data exposure

CONSTRAINTS:
- Focus on OWASP Top 10 where applicable
- Do NOT include actual malicious payloads
- Include expected secure behavior

FORMAT:
| Test ID | Security Risk | Attack Vector | Expected Secure Behavior |

FEATURE:
[PASTE FEATURE DESCRIPTION]
```

## RTCFR AND RICE POT. 
## Template 6: Regression Test Suite
```
ROLE: You are a QA Lead planning regression testing.

TASK: Generate a regression test suite for [MODULE].

PRIORITIES:
1. Critical business flows
2. Previously failed areas
3. High-risk integrations
4. Core functionality

CONSTRAINTS:
- Focus on end-to-end scenarios
- Include data setup requirements
- Estimate execution time per test

FORMAT:
| Test ID | Scenario | Data Setup | Steps | Est. Time | Priority |

MODULE DOCUMENTATION:
[PASTE DOCS]
```

- Output must be **deterministic** (same input → same output).
- **Every assertion must be traceable** to a provided input (PRD / screenshot / document).
- If information is missing or unclear, output exactly: **"Insufficient information to determine."**
- If a detail is inferred rather than stated, label it exactly: **"Inference (low confidence)"**.
- Enterprise-grade quality. **Zero invented content.**

- **Format: CSV only.** No preamble, no explanation, no text outside the CSV.
- **Columns, in this exact order:**

```
Scenario, TID, Test Data, Test Case Description, Pre-Condition, Test Steps,
Expected Result, Actual Result, Status, Executed By (QA Name),
Misc (Comments), Priority, Is Automated
```

## Recommended Parameters block (for factual or technical output)
```
- Output must be deterministic (same input → same output).
- Every assertion must be traceable to a provided input.
- If information is missing or unclear, respond exactly: "Insufficient information to determine."
- If a detail is inferred, label it exactly: "Inference (low confidence)".
- Do not invent features, IDs, APIs, error codes, UI elements, or behavior.
- Do not assume default or "typical" system behavior.
```