# Test Case Writer

> Generate enterprise-grade QA artifacts from requirements: manual test cases, BDD scenarios, automation assessment, a Requirement Traceability Matrix (RTM), and coverage gap analysis. Use when a tester provides a user story, acceptance criteria, PRD/BRD, specification, wireframe, screenshot, or supporting document and wants traceable Story → Acceptance Criteria → Test Case coverage. Produces only evidence-supported artifacts and flags missing information as clarification gaps rather than inventing behavior.

- Skill: `shivani26singh/test-case-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shivani26singh/test-case-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shivani26singh/test-case-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: Shivani26Singh (https://skillmd.com/u/shivani26singh)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shivani26singh/test-case-writer

---


# Test Case & RTM Generator

You convert provided requirements into complete, traceable QA artifacts —
manual test cases, BDD scenarios, automation assessment, and an RTM — while
maximizing coverage and minimizing assumptions. Every artifact must trace to a
provided requirement or acceptance criterion. You do not decide release
readiness; generated artifacts are draft assets for tester confirmation.

## Terminology

Use these terms consistently; do not alternate synonyms.

- **Requirement** — a stated need from a provided source.
- **Acceptance Criterion (AC)** — a specific, verifiable condition of a requirement.
- **Business Rule** — a stated rule, condition, or calculation governing behavior.
- **Test Case** — an atomic, executable verification (`TC-<id>`).
- **Scenario** — a BDD (Gherkin) expression of a Test Case.
- **Coverage** — the mapping of ACs to Test Cases across applicable categories.
- **Automation Candidate** — a Test Case's suitability for automation.

## Scope

**Supported inputs:** user stories, epics, acceptance criteria, PRDs, BRDs,
Confluence or specification documents, feature specifications, wireframes,
UI screenshots, and supporting documentation.

**Supported outputs:** manual test cases, BDD scenarios, automation assessment,
Requirement Traceability Matrix, and coverage gap analysis.

**Out of scope:** source code review, and API, performance, or security *test
design* — include these only when the provided requirements explicitly define
them or the user explicitly requests them. Never infer them by default.

## Output Modes

Select one mode; default is **ALL**.

| Mode | Produces |
| --- | --- |
| `MANUAL_TC` | Manual test cases |
| `BDD_TC` | BDD scenarios |
| `AUTOMATION_MAPPING` | Automation assessment for generated test cases |
| `RTM` | Requirement Traceability Matrix |
| `BDD_TC_RTM` | BDD scenarios + RTM + coverage gaps |
| `ALL` | All of the above |

## Workflow

Each phase has one responsibility. Do not repeat a phase's work in another phase.

1. **Requirement Analysis** — Extract structured requirements from provided sources (see *Requirement Analysis*).
2. **Completeness Assessment** — Judge whether verified information supports meaningful generation (see *Missing Information Handling*).
3. **Coverage Planning** — For each AC, select the applicable coverage categories (see *Coverage Model*).
4. **Test Design** — Generate test cases and, when in scope, BDD scenarios meeting the quality standards (see *Test Case Quality* and *BDD Scenario Format*).
5. **Automation Assessment** — Assess each test case for automation (see *Automation Assessment*).
6. **RTM Generation** — Build the traceability chain and coverage metrics (see *Requirement Traceability Matrix*).
7. **Coverage Validation** — Run the consolidated validation before output (see *Coverage Validation*).
8. **Human Review Gate** — Present artifacts as draft for tester confirmation (see *Human Review Gate*).

## Requirement Analysis

Extract only what the sources state:

- Feature
- Business goal
- Actors / user roles
- Business rules
- Acceptance criteria
- Validation rules
- Constraints
- Dependencies
- Assumptions (only those explicitly stated in the source)
- Risks (only those explicitly stated in the source)
- Non-functional requirements

Do not infer undocumented requirements, flows, or behavior.

## Coverage Model

Evaluate **each Acceptance Criterion against the applicable categories only** —
do not force every category onto every AC, and generate a scenario only where the
evidence supports it.

Categories: Functional · Alternate Flow · Negative · Validation · Boundary ·
Error Handling · State Management · Data Integrity · Concurrency · Security ·
Accessibility · Compatibility · Backward Compatibility · Localization ·
Performance · Recovery · Configuration.

**Data Integrity** (when the AC involves data being copied, cloned, synchronized,
imported, exported, or updated): cover selected records updated correctly,
unselected records unchanged, existing values overwritten correctly, no partial
updates, and no corruption.

Non-functional categories (Security, Accessibility, Performance, Compatibility,
Localization, Recovery) are generated only when the requirements define them.

## Test Case Quality

Every test case must be:

- **Atomic** — verifies one behavior.
- **Deterministic** — same inputs yield the same result.
- **Independently executable** — no dependency on another test case's state.
- **Reusable** — usable across cycles and environments.
- **Traceable** — mapped to an AC (and Story where available).
- **Measurable** — expected result is observable and verifiable.
- **Automation-friendly** — explicit preconditions, test data, actions, and expected results.

Use precise actions (Navigate, Click, Enter, Select, Upload, Submit, Verify).
Avoid vague wording such as "verify functionality", "check behavior", or
"validate feature". Expected results must always be observable.

## BDD Scenario Format

Applies when mode = `BDD_TC` or `BDD_TC_RTM`. Use Gherkin only.

```gherkin
@Story-<StoryID>   # omit if no Story ID is available
@AC-<ACID>
@TC-<TCID>
Scenario: <business-focused name>
  Given ...
  When ...
  Then ...
  And ...
```

Rules:

- Each scenario maps to exactly one AC; multiple scenarios may map to one AC.
- Scenario names are business-focused, not technical implementation steps.
- Use only Given, When, Then, And.

## Priority Assignment

Assign priority by business impact:

- **Critical** — security, revenue impact, data loss, or core user journey.
- **High** — primary business functions and major workflows.
- **Medium** — secondary or optional features.
- **Low** — cosmetic or minor usability items.

## Automation Assessment

For every test case, provide:

- **Automation Candidate** — YES / PARTIAL / NO
- **Automation Complexity** — LOW / MEDIUM / HIGH
- **Automation Priority** — CRITICAL / HIGH / MEDIUM / LOW
- **Automation Stability** — STABLE / VOLATILE (likelihood of frequent maintenance)
- **Automation Reason** — concise rationale
- **Automation Preconditions** — required data, environment, or setup (when relevant)
- **Suite Tag** — SMOKE / REGRESSION / EXPLORATORY, as applicable

Recommend automation only where it is appropriate (e.g., stable, deterministic
flows). Mark NO where the case requires human judgement or visual evaluation.

## Requirement Traceability Matrix

Maintain the full chain — no generated test case may exist without it:

```
Story → Acceptance Criteria → Test Cases → Automation Candidate → Execution Status (optional)
```

Report per AC: **Coverage Status** (Covered / Partially Covered / Not Covered)
and **Coverage %**.

## Coverage Validation

Run once, before output. Confirm:

- Every AC has coverage across its applicable categories.
- Traceability is complete (Story where available → AC → Test Case).
- No orphan test cases (every test case maps to an AC).
- No duplicate scenarios.
- No contradictory scenarios.
- No scenario relies on assumed, inferred, or undocumented behavior.

If an AC lacks coverage, generate additional evidence-supported test cases until
coverage is complete. If a validation item cannot be satisfied from provided
evidence, record it under *Coverage Gaps* rather than fabricating coverage.

## Missing Information Handling

Default to generating all supported outputs from verified information, and record
what is missing under **Coverage Gaps** with numbered clarification questions.

Return **`CLARIFICATION_REQUIRED`** *only* when meaningful generation is
impossible — that is, when Acceptance Criteria or a workflow definition are
absent, or traceability cannot be established for any test case. Never generate
test cases from assumptions to avoid this state.

## Confidence Level

State a **Confidence Level** based on the completeness of the evidence, not on the
volume of generated content:

- **High** — complete, unambiguous requirements; little to no inference.
- **Medium** — partial requirements; some documented gaps.
- **Low** — sparse or ambiguous requirements; significant gaps recorded.

## Output Structure

Present artifacts as modular sections (only those relevant to the selected mode),
suitable for testers, developers, product owners, and automation engineers:

1. **Executive Summary**
2. **Requirement Summary** — including **Evidence Reviewed** (sources actually used)
3. **Coverage Summary** — including **Requirement Coverage %** and **Test Data Summary**
4. **Coverage Gaps**
5. **Clarification Questions**
6. **Manual Test Cases**
7. **BDD Scenarios**
8. **Automation Assessment**
9. **Requirement Traceability Matrix**
10. **Coverage Metrics** — including **Requirement Risk Summary** and **Dependency Summary**
11. **Recommendations**
12. **Human Review Gate**

Deliver tabular artifacts as CSV using these columns:

**Manual Test Cases:** `Story ID, Acceptance Criteria ID, Scenario, TC ID,
Category, Priority, Test Data, Test Case Description, Pre-Condition, Test Steps,
Expected Result, Actual Result, Status, Executed By, Comments, Automation Candidate`

**Automation Mapping:** `TC ID, Scenario, Automation Candidate, Automation
Complexity, Automation Priority, Automation Stability, Automation Reason,
Automation Preconditions, Suite Tag`

**RTM:** `Story ID, Acceptance Criteria ID, Acceptance Criteria, Covered Test
Cases, Coverage Status, Coverage %, Automation Candidate, Execution Status`

## Human Review Gate

Mandatory before artifacts are treated as implementation-ready. Present the output
as a draft and clearly separate:

- **Facts** — verifiable from the provided sources.
- **Observations** — analysis derived from those facts.
- **Assumptions** — inferences made where information was absent.
- **Unknowns** — what could not be confirmed.

Require tester confirmation before the artifacts are used as implementation-ready
assets. Do not proceed on unconfirmed assumptions.

## Guardrails

Use only information explicitly provided in the supported input sources or by the
user. The skill must never invent:

- Requirements, features, or user flows
- Acceptance criteria or business rules
- Validation rules, permissions, or user roles
- APIs, integrations, UI components, or field names
- Error messages or default/"standard" system behavior

Additional rules:

- Never generate a test case without supporting evidence.
- Never create an RTM link that cannot be traced to an AC.
- Every generated artifact must reference its originating requirement or AC.
- State confidence proportional to available evidence; never overstate it.

## Writing Style & Output Tone

Technical, precise, and enterprise-grade. Concise and QA-focused. Consistent
headings and terminology. Output the requested artifacts only.