Skill: Test Case Generation

Purpose

Generate comprehensive test cases from acceptance criteria and requirements to ensure thorough quality validation.

When to Use

• Story has acceptance criteria ready for testing
• New feature needs test coverage
• Regression tests need creation
• Edge cases need documentation
• Test plan requires detailed scenarios

---

Test Case Structure

Standard Test Case Format

## TC-{{id}}: {{testCaseName}}

**Story:** {{storyKey}}
**Priority:** Critical | High | Medium | Low
**Type:** Functional | Integration | E2E | Performance | Security

### Preconditions
- {{precondition1}}
- {{precondition2}}

### Test Data
| Variable | Value | Notes |
|----------|-------|-------|
| {{var}} | {{value}} | {{notes}} |

### Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | {{action}} | {{expected}} |
| 2 | {{action}} | {{expected}} |
| 3 | {{action}} | {{expected}} |

### Postconditions
- {{postcondition}}

### Notes
{{additionalNotes}}

---

Generation Strategy

Coverage Matrix

For each acceptance criterion, generate:

AC Element	Test Types Needed
Happy path	Positive test
Validation rule	Boundary tests, invalid input tests
Error condition	Negative tests
Edge case	Edge case tests
Performance requirement	Performance test
Security requirement	Security test

Test Type Distribution

Per Feature:
├── Positive Tests (Happy Path)     ~30%
├── Negative Tests (Error Cases)    ~30%
├── Boundary Tests (Limits)         ~20%
├── Edge Case Tests                 ~15%
└── Security/Performance            ~5%

---

Test Generation Templates

Positive Test (Happy Path)

## TC-{{id}}: {{feature}} - Successful {{action}}

**Priority:** High
**Type:** Functional

### Preconditions
- User is logged in
- Required data exists

### Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Navigate to {{page}} | Page loads successfully |
| 2 | Enter {{validInput}} in {{field}} | Input accepted |
| 3 | Click {{button}} | {{successResult}} |

### Expected Outcome
- {{successState}}
- {{dataChange}}

Negative Test (Error Handling)

## TC-{{id}}: {{feature}} - {{errorCondition}}

**Priority:** High
**Type:** Functional

### Preconditions
- User is logged in

### Test Data
| Input | Value | Why Invalid |
|-------|-------|-------------|
| {{field}} | {{invalidValue}} | {{reason}} |

### Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Enter {{invalidValue}} in {{field}} | Input shown |
| 2 | Click {{button}} | Error displayed |
| 3 | Verify error message | Shows "{{errorMessage}}" |

### Expected Outcome
- Form does not submit
- Data is not changed
- User can correct and retry

Boundary Test

## TC-{{id}}: {{field}} - {{boundaryType}} Boundary

**Priority:** Medium
**Type:** Boundary

### Boundary Definition
- **Field:** {{field}}
- **Min:** {{min}}
- **Max:** {{max}}

### Test Data
| Scenario | Value | Expected |
|----------|-------|----------|
| Below min | {{min-1}} | Rejected |
| At min | {{min}} | Accepted |
| At max | {{max}} | Accepted |
| Above max | {{max+1}} | Rejected |

### Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Enter {{boundaryValue}} | {{expected}} |
| 2 | Submit form | {{result}} |

Security Test

## TC-{{id}}: {{feature}} - {{securityScenario}}

**Priority:** Critical
**Type:** Security

### Attack Vector
{{attackDescription}}

### Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Attempt {{attack}} | Attack is blocked |
| 2 | Verify no data exposure | No sensitive data shown |
| 3 | Check logs | Attack attempt logged |

### Payloads to Test

{{payload1}} {{payload2}}

### Expected Outcome
- Attack is prevented
- No data leakage
- Appropriate error message (no details)

---

Test Case Categories

Form Testing Suite

## Test Suite: {{formName}} Form

### Field Validation Tests

#### {{fieldName}}
| TC ID | Scenario | Input | Expected |
|-------|----------|-------|----------|
| TC-001 | Valid {{field}} | {{validValue}} | Accepted |
| TC-002 | Empty {{field}} | (blank) | "Required" error |
| TC-003 | {{field}} too short | {{shortValue}} | "Min length" error |
| TC-004 | {{field}} too long | {{longValue}} | "Max length" error |
| TC-005 | {{field}} invalid format | {{badFormat}} | "Invalid format" error |
| TC-006 | {{field}} special chars | {{specialChars}} | {{expected}} |

### Form Submission Tests
| TC ID | Scenario | Expected |
|-------|----------|----------|
| TC-010 | All valid inputs | Success message, data saved |
| TC-011 | Network error | Error message, retry option |
| TC-012 | Server error (500) | Friendly error, no data loss |
| TC-013 | Duplicate submission | Prevented or handled |

CRUD Testing Suite

## Test Suite: {{entity}} CRUD

### Create Tests
| TC ID | Scenario | Expected |
|-------|----------|----------|
| TC-C01 | Create with all fields | Success |
| TC-C02 | Create with required only | Success |
| TC-C03 | Create missing required | Error |
| TC-C04 | Create duplicate | Error or handled |

### Read Tests
| TC ID | Scenario | Expected |
|-------|----------|----------|
| TC-R01 | View existing | Data displayed |
| TC-R02 | View non-existent | 404 or empty state |
| TC-R03 | View unauthorized | 403 |
| TC-R04 | List pagination | Correct page data |

### Update Tests
| TC ID | Scenario | Expected |
|-------|----------|----------|
| TC-U01 | Update valid changes | Success |
| TC-U02 | Update with invalid data | Validation error |
| TC-U03 | Update non-existent | 404 |
| TC-U04 | Concurrent update | Conflict handled |

### Delete Tests
| TC ID | Scenario | Expected |
|-------|----------|----------|
| TC-D01 | Delete existing | Success |
| TC-D02 | Delete non-existent | 404 |
| TC-D03 | Delete with dependencies | Error or cascade |
| TC-D04 | Delete unauthorized | 403 |

API Testing Suite

## Test Suite: {{endpoint}} API

### Request Validation
| TC ID | Scenario | Input | Expected Status |
|-------|----------|-------|-----------------|
| TC-A01 | Valid request | {{validBody}} | 200/201 |
| TC-A02 | Missing required field | {{missingField}} | 400 |
| TC-A03 | Invalid data type | {{wrongType}} | 400 |
| TC-A04 | Malformed JSON | {{badJson}} | 400 |

### Authentication
| TC ID | Scenario | Auth | Expected |
|-------|----------|------|----------|
| TC-A10 | No auth header | None | 401 |
| TC-A11 | Invalid token | Bad token | 401 |
| TC-A12 | Expired token | Expired | 401 |
| TC-A13 | Valid token | Good token | 200 |

### Authorization
| TC ID | Scenario | Role | Expected |
|-------|----------|------|----------|
| TC-A20 | Admin access | Admin | 200 |
| TC-A21 | User access | User | 200 or 403 |
| TC-A22 | Guest access | None | 401 |

---

Test Data Generation

Data Patterns

Data Type	Valid Examples	Invalid Examples
Email	test@example.com	test, @.com, test@
Phone	+1234567890	abc, 123
Password	SecureP@ss1	123, password
Date	2025-01-15	01-15-2025, invalid
URL	https://example.com	not-a-url, ftp://
Number	42, 0, -5	abc, 12.34.56

Boundary Values

Constraint	Values to Test
Min: 0	-1, 0, 1
Max: 100	99, 100, 101
Length: 1-50	"", "a", "a"×50, "a"×51
Required	null, undefined, "", valid

---

Test Execution Tracking

## Test Execution: {{storyKey}}

**Tester:** QA Engineer Agent
**Date:** {{date}}
**Environment:** {{environment}}

### Results Summary
| Status | Count |
|--------|-------|
| Passed | {{passed}} |
| Failed | {{failed}} |
| Blocked | {{blocked}} |
| Skipped | {{skipped}} |

### Test Results
| TC ID | Title | Status | Notes |
|-------|-------|--------|-------|
| TC-001 | {{title}} | Pass/Fail | {{notes}} |

### Defects Found
| TC ID | Defect | Severity | Jira |
|-------|--------|----------|------|
| TC-005 | {{defect}} | {{severity}} | {{bugKey}} |

---

Used By Agents

Agent	Test Case Generation Use
QA Engineer	Primary - generates all test cases
Business Analyst	May draft AC-based cases
Senior Developer	May generate unit test cases
DevOps Engineer	May generate deployment verification tests

Best Practices

1. Trace to AC - Every AC should have at least one test
2. Be specific - Exact inputs and expected outputs
3. Include test data - Don't make testers guess
4. Prioritize - Critical paths get more tests
5. Consider combinations - Field interactions matter
6. Automate where possible - Flag tests suitable for automation