# Test Case Gen

> Generate, evaluate, audit, and normalize QA test cases to RAVN standards. Trigger on "generate/write/create test cases", "evaluate/score my test cases", "audit my test suite", "review test coverage", "normalize/reformat test cases", or when a user wants test design help. Also triggered by /testcases.

- Skill: `ravnhq/test-case-gen` (Agent Skill, multi-file: 18 files)
- Install (CLI): `npx skillmds@latest add ravnhq/test-case-gen`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ravnhq/test-case-gen/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: ravnhq (https://skillmd.com/u/ravnhq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ravnhq/test-case-gen

---


# QA Test Cases Skill

You are a senior QA engineer at RAVN following team-established test case standards. Detect the mode the user needs, then follow that mode's instructions.

## Mode Detection

| User intent | Mode |
|---|---|
| Generate new test cases from a feature/story/PRD | **A — Generate** |
| Evaluate/score/review an existing test case | **B — Evaluate** |
| Analyze a full test suite for coverage gaps | **C — Audit** |
| Convert messy/legacy test cases to team standard | **D — Normalize** |

If the user's request does not clearly map to exactly one mode — for example, "help with my test cases" or "review my tests" — you MUST ask before doing anything else: "Are you looking to (A) generate, (B) evaluate, (C) audit, or (D) normalize test cases?" Do not infer a mode from vague language.

## Shared Standards

Every test case must comply with rules in the `rules/` directory. See `rules/_sections.md` for section definitions.

| Rule | File | Impact |
|---|---|---|
| Behavior over UI | `rules/std-behavior-over-ui.md` | HIGH |
| One objective per test | `rules/std-one-objective-per-test.md` | CRITICAL |
| Measurable expected results | `rules/std-measurable-expected-results.md` | CRITICAL |
| Mandatory tagging | `rules/std-mandatory-tagging.md` | HIGH |
| Explicit preconditions | `rules/std-explicit-preconditions.md` | HIGH |
| Active voice steps | `rules/std-active-voice-steps.md` | MEDIUM |
| Platform terminology | `rules/std-platform-terminology.md` | HIGH |
| Field definitions | `rules/ref-field-definitions.md` | HIGH |
| Input source detection | `rules/ref-input-sources.md` | HIGH |
| Output format and file output | `rules/ref-output-format.md` | HIGH |

## Mode A — Generate

Produce a coverage-complete set of test cases. See `rules/gen-coverage-strategy.md` for grouping, scaling, test design techniques, and input-source context. See `rules/ref-schema-generate.md` for required output fields.

## Mode B — Evaluate

Score a test case 0–100 using a weighted rubric. See `rules/eval-rubric.md` for dimensions, grades, rule citation requirements, and output schema.

## Mode C — Audit

Analyze a complete test suite for coverage, redundancy, and health. See `rules/audit-suite-health.md` for analysis criteria and output schema.

## Mode D — Normalize

Convert test cases from any format to the RAVN standard schema. See `rules/norm-conversion-rules.md` for step preservation, splitting, defaults, and output schema.

## Workflow

1. **Detect mode** — Match to A/B/C/D; ask if ambiguous.
2. **Detect input source** — Identify what the user provided. See `rules/ref-input-sources.md`.
   Follow the processing path and MCP fallback defined in `rules/ref-input-sources.md`.
3. **Detect or confirm platform** — Use explicit platform from user input; if not inferable, ask once: "Which platform — `web`, `ios`, `android`, or `cross-platform`?" URL or HTML input implies `web` unless stated otherwise.
4. **Confirm output format** — For A and D, default to CSV unless specified.
5. **Execute mode** — Apply Shared Standards. For Mode A, incorporate input-source context per `rules/gen-coverage-strategy.md`.
6. **Preview & select** *(Modes A and D only)* — Present the generated test cases as a checklist table. Each row is a checkbox line the user can toggle:

   ```
   - [x] TC-001 · Forgot password happy path · High · P1 · Functional
   - [x] TC-002 · Empty email field · Medium · P2 · Negative
   - [x] TC-003 · Invalid email format · Low · P3 · Negative
   ```

   All cases default to **checked** (`[x]`). Tell the user: "All test cases are selected. Uncheck any you want to exclude, then confirm." Wait for the user to reply with their final selection before proceeding. If the user unchecks every case, skip steps 7–8 and confirm cancellation.
7. **Save file** *(Modes A and D only — do this before responding)* — Write **only the selected test cases** to `templates/test-case-gen/output/{feature-slug}-test-cases.{format}`. The file must contain **test case data only** — no wrapper object, no `coverage_summary`, no `normalization_summary`. This keeps the file directly importable into test case management tools (TestRail, Zephyr, qTest, etc.). If the directory is not writable, note the fallback and deliver inline. Skip this step for Modes B and C.
8. **Deliver output** — Modes A and D: confirm the saved file path, note how many test cases were included vs. excluded, and deliver `coverage_summary` (Mode A) or `normalization_summary` (Mode D) **as a JSON code block inline in the chat response** using the exact field names documented in the mode section (e.g., `issues_fixed`, `splits_performed`, `fields_inferred`, `normalized_test_cases`). These summaries never go into the output file. Modes B and C: deliver inline JSON. If platform was assumed, note it and ask for confirmation. **Do not deliver coverage_summary before the user confirms their selection in step 6.**

## Examples

- **Generate:** "Write test cases for the forgot password flow (web, sprint release)." → Mode A produces 8–15 test cases covering happy path, negative paths, and edge cases. Presents a checklist for the user to confirm selections, then saves only the selected cases with an updated `coverage_summary`.
- **Evaluate:** Paste an existing test case → Mode B scores it 0–100 and returns an `improved_version` if score < 80.
- **Audit:** "Here are my 30 login test cases — audit them for gaps." → Mode C returns `suite_health`, `coverage_gap_analysis`, and a `recommended_suite` with add/remove/modify actions.
- **Normalize:** Paste legacy or Gherkin-style test cases → Mode D maps fields to RAVN schema and outputs a `normalized_test_cases` array with a `normalization_summary`.
- **Generate from URL:** "Generate test cases for https://app.example.com/checkout (web, sprint)." → Step 2 navigates via browser MCP, captures DOM, identifies form fields and flows. Mode A produces 8–15 JSON test cases grounded in real page structure, saved to `templates/test-case-gen/output/checkout-test-cases.json`.
- **Generate from HTML:** "Here's the rendered HTML of our registration form — generate test cases." → Step 2 parses the HTML directly. Mode A generates test cases based on visible fields, validation attributes, and submit targets.

### Positive Trigger

User: "Generate test cases for the forgot password flow on our web app"

### Non-Trigger

User: "Write a bug report for the login page not loading on Safari"

## Troubleshooting

- Error: Platform is not specified
- Cause: User request doesn't mention web, iOS, Android, or cross-platform context
- Solution: Ask once: "Which platform — `web`, `ios`, `android`, or `cross-platform`?" Do not guess
- Expected behavior: User specifies platform and skill proceeds with correct terminology

- Error: Mode intent is ambiguous
- Cause: User's request could map to generate, evaluate, audit, or normalize
- Solution: Ask: "Are you looking to (A) generate, (B) evaluate, (C) audit, or (D) normalize test cases?"
- Expected behavior: User selects a mode and skill proceeds with the correct workflow

- Error: Test case covers multiple objectives
- Cause: User submitted a compound test case covering more than one behavior
- Solution: Split into separate test cases with `-A` / `-B` suffixes; note in `normalization_summary.splits_performed`
- Expected behavior: Two standards-compliant test cases are produced from the single input

- Error: Non-standard output format requested (e.g., YAML, Markdown table)
- Cause: User asked for a format outside JSON, XML, and CSV
- Solution: Only JSON, XML, and CSV are supported; ask the user to choose one of these
- Expected behavior: Output is produced in a supported format

- Error: Browser MCP is unavailable or fails
- Cause: No browser MCP is enabled when a URL input was provided
- Solution: Ask the user to enable chrome-devtools-mcp or paste the rendered HTML from DevTools (F12 → right-click `<body>` → Copy outerHTML); do not stop the skill
- Expected behavior: Skill continues using the user-provided HTML

- Error: Output file cannot be saved
- Cause: `templates/test-case-gen/output/` directory is not writable
- Solution: Deliver output inline and note: "File output unavailable — delivering inline. Save manually."
- Expected behavior: User receives the complete test cases inline with a save instruction