input-sources

name	input-sources
description	Multi-source input handling for manual test case generation. Use when the input is NOT a Jira Story ID — covers User Stories, Business Flows/Processes, Use Cases, and REST API endpoint specifications. Covers input type detection, requirements extraction, reference ID generation, and test derivation rules for each source type.
user-invocable	false

Input Sources Reference

Step 0: Input Type Detection

Before any other step, classify the user's input as one of:

Input Type	Detection Signal
Jira Story	Alphanumeric ID matching pattern [A-Z]+-\d+ (e.g., PS-12345, PROJ-99)
User Story	Contains "As a [role], I want to [action]" or "As a [role] I can [action]"
Business Flow	Step-by-step process description: numbered steps, swimlane descriptions, process narratives
Use Case	Structured with Actor, Preconditions, Main Flow, Alternative Flows, Exceptions
API Specification	Contains HTTP method (GET/POST/PUT/PATCH/DELETE), endpoint path, request/response schema or payload
Mixed / Freeform	Combination of above, or plain description of a feature/requirement

If ambiguous, ask the user: "Is this a Jira Story ID, User Story, Business Flow, Use Case, or API Specification? Or paste all context and I will classify it."

---

Reference ID Generation (Non-Jira Sources)

Since there is no Jira key, derive a reference ID for artifact paths and test case IDs:

Source Type	Reference ID Pattern	Example
User Story	US-<slug> (2-4 word slug from title)	US-EMPLOYEE-EXPORT
Business Flow	BF-<slug>	BF-ORDER-CHECKOUT
Use Case	UC-<slug>	UC-LOGIN-FLOW
API Endpoint	API-<METHOD>-<resource>	API-POST-PAYMENTS
Freeform	FT-<slug>	FT-SEARCH-FILTER

Slug rules: uppercase, hyphens only, max 3 segments, derived from the feature name.

---

Source-Specific Extraction Rules

1. User Story

Format: As a [role], I want to [action] so that [benefit]

Extract:

• Actor: the role (Admin, Employee, Guest, API Consumer...)
• Goal: the action they want to perform
• Value: the benefit/reason
• Implicit ACs: derive from the goal — every distinct outcome the user expects constitutes an implicit acceptance criterion

Test Derivation:

• Positive: User completes the action successfully
• Negative: User lacks permission, provides invalid input, or prerequisites are unmet
• Boundary: Apply BVA/EP to any quantities, limits, or field constraints implied by the story
• Edge: Multiple roles, concurrent actions, empty states

Example:

"As an Admin, I want to export employee history as a CSV so that I can archive records"

Implicit ACs → export triggers download, file is valid CSV, contains all expected fields, handles 0 records, handles large datasets.

---

2. Business Flow / Process

Format: Numbered steps, swimlane descriptions, or process narratives describing how a system or business process works.

Extract:

• Entry Point: What triggers the flow
• Steps: Each step is a potential state or transition → test case candidate
• Branch Points: Decision nodes (if/else, approval/rejection) → test for each branch
• Exit Points: Normal completion, error termination, timeout
• Actors: Who performs each step

Test Derivation:

• Positive: Happy path — all steps succeed in sequence
• Negative: Each branch point's failure/rejection path
• Edge: Skip a step, return to a previous step, concurrent actors, timeout at each step
• State Transition: Use State Transition technique for each decision node

Example flow:

1. User submits form → 2. System validates → 3. Manager approves → 4. System sends confirmation

Test cases: successful submission, validation failure, manager rejects, system confirmation failure, duplicate submission.

---

3. Use Case

Format: Structured with Actor, Preconditions, Main Flow (numbered steps), Alternative Flows, and Exception Flows.

Extract:

• Actor(s): Primary and secondary actors
• Preconditions: Map directly to GIVEN steps
• Main Flow: Generates the primary Positive test case (Use Case Testing technique)
• Alternative Flows: Each generates one additional Positive or Boundary test case
• Exception Flows: Each generates one Negative test case

Test Derivation:

• One test case per main flow
• One test case per alternative flow (alternate success paths)
• One test case per exception flow (error/failure paths)
• Additional boundary cases for any data constraints mentioned

Technique: Use Case Testing for main/alternative flows; Error Guessing for exception flows.

---

4. REST API Endpoint Specification

Extract from the spec:

• HTTP Method + Endpoint path (e.g., POST /api/v1/payments)
• Request schema: required fields, optional fields, field types and constraints
• Response schemas: 200/201 (success), 400 (validation error), 401/403 (auth), 404 (not found), 409 (conflict), 500 (server error)
• Authentication: Bearer token, API key, session
• Business rules embedded in the spec description

Test Derivation:

Test Category	Coverage
Happy Path	Valid request with all required fields → expected 2xx response
Optional Fields	Request with only required fields (no optional) → valid 2xx
Field Validation	Missing required field → 400 with appropriate error message
Field Validation	Invalid type/format per field → 400 with field-specific error
Boundary Values	Min/max values for numeric and string length fields
Authentication	No token / expired token / invalid token → 401
Authorization	Valid token but insufficient permissions → 403
Not Found	Valid request for non-existent resource → 404
Conflict/Duplicate	Creating duplicate resource → 409 (if applicable)
Edge Cases	Empty arrays, null optional fields, Unicode in string fields

Technique Mapping:

• Required field tests → Input Field Validation
• Numeric range/length tests → BVA + EP
• Multiple field combinations → Decision Table (if business rules combine fields)
• Status transitions (e.g., order states) → State Transition

BDD Structure for API Tests:

        GIVEN A valid authentication token is available
        AND The API endpoint POST /api/v1/payments is accessible
        WHEN A POST request is sent with [describe payload]
        THEN The response status code is [expected code]
        AND The response body contains [expected fields/values]
        AND [Additional assertions on headers or side effects]

---

5. Mixed / Freeform Input

When the user provides a feature description without clear structure:

1. Identify distinct functional requirements (what the system must do)
2. Identify any constraints or rules (limits, permissions, states)
3. Treat each functional requirement as an implicit AC
4. Apply the same derivation rules as User Story above

---

AC Numbering for Non-Jira Sources

Since there is no customfield_14400, derive AC numbers from the extracted requirements:

• Number sequentially: AC-1, AC-2, AC-3...
• Each distinct functional requirement or testable behavior = one AC
• Document the extracted ACs in the test case file header under "Derived Requirements"

---

Feature Toggle Handling for Non-Jira Sources

• If the spec/story mentions a feature flag or toggle → include it in GIVEN and create a toggle-OFF test case
• If no toggle is mentioned → omit toggle test case; note in the file header: Feature Toggle State : N/A

---

Header Adaptation for Non-Jira Sources

Use the non-Jira header variant from the test-case-template skill:

Field	Jira Source	Non-Jira Source
Story ID & Title	Jira key + summary	Reference ID + derived title
Value Stream	customfield_22200	User-provided or "N/A"
Subvalue Stream	customfield_22201	User-provided or "N/A"
Portfolio Team	customfield_15604	User-provided or "N/A"
Story Description	Rewrite from Jira description	Rewrite from provided input
Derived Requirements	Not needed	List of extracted ACs