/testgen-flow-test-case-generation

name: testgen-flow-test-case-generation
description: "Phase 5 Test Case Generation of testgen-flow"
alwaysApply: false
disable-model-invocation: true
user-invocable: false
baseSchema: docs/schemas/phase.md

<testgen_flow_test_case_generation>

<description_and_purpose> Generate comprehensive test cases from the requirements document, covering all requirement types with appropriate test scenarios. Merge redundant cases via parameterization, build coverage matrix. </description_and_purpose>

<workflow_context>

• Phase 5 of 7 in `testgen-flow`
• Input: `requirements.md` from Phase 4
• Output: `test-scenarios.md` — test cases
• Required skills: `qa-knowledge` (`scenario_design` mode + config-resolved TMS FORMAT binding)
• Recommended skills: `coding` (for any tracked write outside the ticket folder; read repo standards as authority)
• Prerequisite: Phase 0-4 complete with validated requirements

</workflow_context>

<phase_steps> 1. Load requirements 2. Identify test scenario types per requirement 3. Generate test cases in TMS format 4. Prioritize test cases 5. Merge redundant test cases 6. Build traceability and coverage 7. Create test cases document 8. Update traceability in requirements 9. Update state file </phase_steps>

<load_requirements step="5.1"> 1. Read `plans/testgen-{TICKET-KEY}/requirements.md` 2. Extract all user stories (US-N), functional requirements (FR-N), non-functional requirements (NFR-N) with acceptance criteria 3. Extract constraints and dependencies that affect test design </load_requirements>

<identify_test_types step="5.2"> For each requirement, determine test scenario types needed:

• **Happy Path**: primary flow, all valid inputs, all preconditions met
• **Edge Cases**: boundary values (min, max, zero, empty), special characters, large data sets
• **Negative Tests**: invalid inputs, missing required fields, unauthorized access, timeouts
• **Integration Tests**: external system interactions, API calls, database operations
• **Performance Tests** (for NFRs): load, stress, concurrent users, response time
• **Security Tests** (for security NFRs): auth failures, authorization violations, injection, XSS

**Scope guard:** generate **Performance** and **Security** test types ONLY when the requirements / NFRs specify a constraint in that category — never invent injection / XSS / load tests without a source requirement (mirrors the Phase 4 NFR coverage-discipline: cover only what the sources specify, do not pad).

Common patterns for minimum coverage:

**CRUD Operations** (4+ scenarios):

• Create with valid data (Happy Path)
• Read existing record (Happy Path)
• Update existing record (Happy Path)
• Delete record (Happy Path)
• Create with invalid data (Negative)
• Read/Update/Delete non-existent record (Negative)

**Authentication** (5+ scenarios):

• Login with valid credentials (Happy Path)
• Login with invalid password (Negative)
• Login with non-existent user (Negative)
• Login after account locked (Negative)
• Logout successfully (Happy Path)

**API Calls** (4+ scenarios):

• Successful request with valid data (Happy Path)
• Request with invalid data (Negative)
• Request with missing auth token (Negative)
• Request with network timeout (Negative)

</identify_test_types>

<generate_test_cases step="5.3" subagent="engineer" role="Test case design engineer">

**Resolve the TMS FORMAT provider first** (merge evidence — do NOT hardcode the vendor): read the TMS provider from `plans/testgen-{TICKET-KEY}/testgen-project-config.md` (data sources / provider fields written by Phase 0, prefilled from `gain.json` `sdlc.test_management(_project)`), explicit user input (wins for this run), or a recognizable TMS URL/handle; conflicting evidence → ask about the TMS only. The resolved provider (e.g. `testrail`, the canonical example) is passed to `qa-knowledge` (`scenario_design` mode) for the vendor-specific case format (the skill loads its own `<vendor>-format` binding internally). If no provider resolves but a TMS is clearly in scope, re-read config; if still absent, fall back to the inline `<tc_schema>` template below (record the fallback per `<failure_handling>`).

1. USE SKILL `qa-knowledge` (`scenario_design` mode) passing the resolved TMS provider for the test case format. 2. Create 2-5 test cases per requirement covering different test types from step 5.2. 3. Apply `<format_rules>` (forbidden fields), `<tc_schema>` (field-level template), and `<title_quality>` (naming) sub-blocks below.

<format_rules> **Single source of truth for TMS-compatibility constraints** — referenced by `<tc_schema>` Notes, `<validation_checklist>`, and `<pitfalls>`; do not restate elsewhere.

Test cases MUST use the **`Steps + Expected Result`** shape so they map cleanly to the TMS's separated steps/expected fields used by Phase 6 export (TestRail's `custom_steps_separated` / `custom_expected` are the canonical example).

**NOT permitted** (each breaks Phase 6 export — re-grep `test-scenarios.md` per `<validation_checklist>`):

• BDD / Gherkin / Given-When-Then format — `Given `, `When `, `Then ` step shapes
• `Post-conditions` field — encode teardown into the test framework or note residual side effects in Expected Result
• `Automation` field — automation status is TMS metadata or framework concern, not part of the case body

The `qa-knowledge` scenario_design FORMAT binding enforces these on the normal path; the rules are restated here once so they survive when the skill cannot load. </format_rules>

<tc_schema> Every test case (TC-NNN) MUST have these fields, in this order. If the `qa-knowledge` scenario_design mode (or its resolved FORMAT binding) is unavailable or returns an incompatible shape, use this template so Phase 5 output is self-contained:

### TC-NNN: [Concise test case title]

**Priority:** P0 | P1 | P2 | P3
**Type:** Happy Path | Edge Case | Negative | Integration | Performance | Security
**Source Requirement(s):** US-N, FR-N, NFR-N (one or more)

**Preconditions:**