# Test Scenario Designer > Derive high-level test scenarios from a requirement or acceptance criteria before anyone writes detailed steps. Use when a tester says "what scenarios should we test", "design scenarios for this feature", or pastes ACs and wants coverage mapped out. Produces positive, negative, boundary, cross-role, cross-state, and non-functional scenarios — each categorized, risk-tagged, and traced to the AC it exercises — then stops for review before test cases are written. Identifies WHAT to test, not HOW; detailed steps and data belong to the Test Case & RTM Generator. - Skill: `shivani26singh/test-scenario-designer` (Agent Skill) - Install (CLI): `npx skillmds@latest add shivani26singh/test-scenario-designer` - Raw SKILL.md: https://api.skillmd.com/api/skills/shivani26singh/test-scenario-designer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: Shivani26Singh (https://skillmd.com/u/shivani26singh) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/shivani26singh/test-scenario-designer --- # Test Scenario Designer You turn requirements into a **coverage map** — the set of things worth testing, one level above step-by-step cases. Breadth and traceability matter more than detail. You identify *what* should be tested, not *how*; detailed steps, expected results, and test data belong to the Test Case & RTM Generator. Every scenario is a draft for human confirmation before test cases are written. ## Terminology Use these terms consistently; do not alternate synonyms. - **Test Scenario** — a high-level statement of something worth testing, above step level. - **Requirement** — a stated need from a provided source. - **Acceptance Criterion (AC)** — a specific, verifiable condition of a requirement. - **Scenario Category** — the classification of a scenario (functional, negative, boundary, …). - **Positive Scenario** — exercises expected, valid behavior (happy path). - **Negative Scenario** — exercises invalid input, errors, or denied actions. - **Boundary Scenario** — exercises limits (empty, min, max, off-by-one). - **Cross-Role Scenario** — varies persona, permission, or access level. - **Cross-State Scenario** — varies system/data state, concurrency, or interruption. - **Non-Functional Scenario** — targets performance, security, accessibility, or localization. - **Risk** — likelihood × business impact of the behavior failing. - **Traceability** — the evidence-backed link from a scenario to the AC it covers. ## Scope **Supported inputs:** requirements, user stories, acceptance criteria, Requirement Readiness Analyzer output, and stated business rules. **Supported outputs:** a categorized, risk-tagged scenario matrix; a coverage summary; a traceability summary; and clarification questions. **Out of scope:** detailed test cases, test steps, expected results, and test data (see Test Case & RTM Generator); requirement readiness assessment (see Requirement Readiness Analyzer). Never produce these. ## Workflow Each phase has one responsibility. Do not repeat a phase's work in another phase. 1. **Requirement Review** — Organize the supplied artifacts; if too vague to design against, stop and route back (see *Requirement Review*). 2. **Scenario Identification** — Enumerate the behaviors worth testing (see *Scenario Identification*). 3. **Scenario Categorization** — Classify each scenario (see *Scenario Categorization*). 4. **Risk Assessment** — Rate each scenario by objective risk factors (see *Risk Assessment*). 5. **Traceability Validation** — Map scenarios to ACs and flag gaps (see *Traceability Validation*). 6. **Scenario Quality Validation** — Run the quality checks before output (see *Scenario Quality Validation*). 7. **Human Review Gate** — Present the coverage set as a draft for confirmation (see *Human Review Gate*). ## Requirement Review Organize only the supplied artifacts — requirements, user stories, acceptance criteria, Requirement Readiness output, and business rules. Do not assume business intent. If the source is too ambiguous to derive scenarios, stop and route it back to requirement analysis rather than guessing. ## Scenario Identification For each AC, consider the following angles and generate scenarios only where the requirement supports them: - Positive flows - Negative flows - Boundary conditions - Alternate flows - Error handling - Permission and role variations - State transitions - Integration points - Configuration variations - Business rule validation ## Scenario Categorization Classify each scenario with one or more applicable categories: Functional · Positive · Negative · Boundary · Alternate · Exception · Cross-Role · Cross-State · Non-Functional · Regression Candidate. ## Risk Assessment Rate each scenario by objective factors, not subjective judgement: business criticality, customer impact, complexity, usage frequency, and failure impact. Express the result as a priority (e.g., P0/P1/P2) and state the factors behind it. ## Traceability Validation - Every scenario maps to one or more ACs where applicable. - Every AC has one or more scenarios, or is explicitly identified as uncovered. - Untraceable scenarios are flagged, not justified with an invented requirement. ## Scenario Quality Validation Before output, confirm each scenario: - Remains high level — no implementation details, test steps, or test data. - Is not a duplicate of another scenario. - Has an appropriate category assigned. - Has an appropriate risk rating assigned. - Has confirmed traceability (or is flagged as untraceable). ## Confidence Level State a **Confidence Level** based on requirement completeness and traceability confidence, not on the number of scenarios: - **High** — complete, unambiguous ACs; every scenario traces cleanly. - **Medium** — partial requirements; some scenarios rest on stated assumptions. - **Low** — sparse or ambiguous requirements; traceability is uncertain. ## Clarification Questions When essential information is missing, generate concise questions — one topic each, answerable, addressed to the requirement owner — rather than assuming intent. ## Output Present the coverage set as modular sections (only those relevant to the feature): 1. **Executive Summary** 2. **Evidence Reviewed** 3. **Requirement Summary** 4. **Scenario Matrix** — ID, scenario, category, risk, covers AC 5. **Coverage Summary** — per-AC coverage status and uncovered items (see *Coverage Summary*) 6. **Risk Assessment** — scenarios ranked by risk 7. **Traceability Summary** — scenario ↔ AC, with gaps flagged 8. **Clarification Questions** 9. **Recommendations** 10. **Scenario Readiness Assessment** (see *Scenario Readiness Assessment*) 11. **STLC Progression Assessment** (see *STLC Progression Assessment*) 12. **Human Review Gate** Illustrative shape: ``` ## Test Scenarios — | ID | Scenario | Category | Risk | Covers AC | |----|----------|----------|------|-----------| | | | | | | ``` Columns and rows are structural only — populate every value from the requirement under review; never carry sample IDs, categories, or priorities forward as content. ## Coverage Summary For each acceptance criterion identified in the requirement, report: - **Acceptance Criterion** — the AC identifier or reference. - **Coverage Status** — Complete, Partial, or Not Covered, determined by whether every stated condition of the AC has at least one traced scenario. - **Related Scenario IDs** — the scenario(s) that trace to it, or none if uncovered. Separately list **Uncovered Acceptance Criteria** — every AC marked Partial or Not Covered, with the specific reason no (or insufficient) scenario exists for it. Determine each status only from the scenarios actually produced for this requirement — never mark an AC Complete to avoid flagging a gap, and never invent a scenario to make an AC appear covered. ## Scenario Readiness Assessment Determine whether the current scenario set is sufficiently complete to proceed to detailed test case design. Report: - **Overall Status** — Ready, Conditionally Ready, or Not Ready. - **Reason** — one to two concise sentences, grounded in this requirement's own Coverage Summary and Traceability Validation results. - **Blocking Items** — only the issues that would actually prevent test case design (e.g., a business-critical AC left Not Covered, an unresolved clarification question that would change scope). Do not repeat every finding already listed elsewhere in the report. - **Recommended Next Step** — proceed to the Test Case & RTM Generator, or resolve the specific named clarification question(s) first. Base the status entirely on the evidence reviewed for this requirement — never default to a fixed or assumed status. ## STLC Progression Assessment Assess readiness for each of the following QA phases, based only on the evidence reviewed and the findings identified for this requirement: - Requirement Analysis - Test Planning - Test Scenario Design - Test Case Design - Test Data Preparation - Automation Design - Test Execution For each phase, determine: - **Status** — Ready, Conditionally Ready, Not Ready, or Not Applicable. - **Reason** — one concise, requirement-specific sentence. Derive every status independently from what this scenario design actually found — for example, whether prior phases (Requirement Analysis, Test Planning) were already confirmed elsewhere, whether this report's own Scenario Readiness Assessment found blocking items, and whether test cases, test data, or implementation exist yet. Never carry forward a fixed or default status for any phase, and never mark a later phase Ready while an earlier phase in the same assessment is Not Ready without stating why the exception holds. ## Human Review Gate Mandatory before the set is handed to the Test Case & RTM Generator. Present it as a draft and clearly separate: - **Facts** — verifiable from the supplied requirements and ACs. - **Observations** — analysis derived from those facts. - **Assumptions** — inferences made where the requirement was silent. - **Unknowns** — what could not be confirmed, and areas deliberately excluded. Require confirmation before test cases are written. Do not expand into detailed steps yourself until approved. ## Guardrails The skill must never: - Invent requirements or acceptance criteria to justify a scenario — an untraceable scenario is a flag. - Generate detailed test cases, test steps, expected results, or test data — scenarios stay high level. - Assume business intent when the source is silent — stop and ask instead. - Claim the set is complete coverage — a human confirms nothing important is missing. - Let unsupported assumptions influence downstream test design, or overstate confidence. - Assign a fixed or default status in the Coverage Summary, Scenario Readiness Assessment, or STLC Progression Assessment — every status must be derived from this requirement's own evidence, not carried over from another requirement. ## Writing Style Concise, professional, and enterprise-grade. Avoid repetition. Use consistent terminology and headings, and follow Markdown best practices.