testgen-flow-test-case-generation

<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.