Qa Test Planner

<!-- AUTO-GENERATED by export-skills.py — DO NOT EDIT -->
---
name: qa-test-planner
description: Generate comprehensive test plans, manual test cases, regression test suites, and bug reports for QA engineers. Use when creating test strategy for a feature, building regression suites, writing manual test cases with step-by-step instructions, or documenting bugs. Includes Figma design validation support.
---

# QA Test Planner

Comprehensive QA engineering toolkit for creating test plans, generating manual test cases, building regression suites, validating designs, and documenting bugs.

## When to Use

- Creating test strategy for a new feature or epic
- Writing manual test cases with step-by-step instructions
- Building regression test suites (smoke, full, targeted)
- Comparing implementation against Figma designs
- Documenting bugs with reproducible steps

## Quick Reference

| Task | What You Get | Typical Time |
|---|---|---|
| Test Plan | Strategy, scope, schedule, risks | 10-15 min |
| Test Cases | Step-by-step instructions + expected results | 5-10 min each |
| Regression Suite | Smoke tests, critical paths, execution order | 15-20 min |
| Figma Validation | Design-implementation comparison, discrepancy list | 10-15 min |
| Bug Report | Reproducible steps, environment, evidence | 5 min |

## Workflow

```
Your Request
    |
    v
1. ANALYZE
   - Parse feature/requirement
   - Identify test types needed
   - Determine scope and priorities
    |
2. GENERATE
   - Create structured deliverables
   - Apply templates and best practices
   - Include edge cases and boundary values
    |
3. VALIDATE
   - Check completeness
   - Verify traceability to requirements
   - Ensure steps are actionable
    |
    v
QA Deliverable Ready
```

## 1. Test Plans

A test plan defines the strategy, scope, and approach for testing a feature.

### Structure

```markdown
# Test Plan: {Feature Name}

## Scope
- **In Scope**: [What will be tested]
- **Out of Scope**: [What will NOT be tested]

## Test Strategy
- **Functional Testing**: [Approach]
- **Integration Testing**: [Approach]
- **Performance Testing**: [If applicable]
- **Security Testing**: [If applicable]

## Environment Requirements
- Browser/OS matrix
- Test data requirements
- External service dependencies

## Entry Criteria
- [ ] Feature code complete and deployed to staging
- [ ] Test data prepared
- [ ] Test accounts created

## Exit Criteria
- [ ] All critical test cases pass
- [ ] No open P0/P1 bugs
- [ ] Regression suite passes
- [ ] Performance benchmarks met

## Risk Assessment
| Risk | Impact | Mitigation |
|---|---|---|
| [Risk description] | High/Med/Low | [Mitigation plan] |

## Timeline
| Phase | Duration | Owner |
|---|---|---|
| Test case creation | X days | QA |
| Execution | X days | QA |
| Bug fix verification | X days | QA + Dev |
```

## 2. Manual Test Cases

Each test case must be unambiguous and reproducible by someone unfamiliar with the feature.

### Structure

```markdown
## TC-{ID}: {Test Case Title}

**Priority**: P0/P1/P2/P3
**Type**: Functional / Integration / Edge Case / Negative
**Preconditions**:
- User is logged in as {role}
- {Data setup requirements}

### Steps

| Step | Action | Expected Result |
|---|---|---|
| 1 | Navigate to {URL/page} | {Page} is displayed |
| 2 | Enter "{value}" in {field} | Value is accepted |
| 3 | Click "{button}" | {Expected behavior} |
| 4 | Verify {element} | Shows "{expected text/state}" |

**Test Data**: {Specific test data needed}
**Notes**: {Edge cases or special considerations}
```

### Test Case Types

| Type | Focus | Examples |
|---|---|---|
| **Happy Path** | Normal successful flow | Login with valid credentials |
| **Negative** | Invalid inputs, error handling | Login with wrong password |
| **Boundary** | Edge values (min, max, empty) | Username with 1 char, 255 chars |
| **Integration** | Cross-feature interactions | Login then access protected page |
| **Accessibility** | Keyboard, screen reader | Tab through form, ARIA labels |

## 3. Regression Suites

### Smoke Tests (15-30 min)

Critical path tests that verify the application is stable enough for deeper testing.

```markdown
## Smoke Test Suite

**Execution time**: ~20 minutes
**When to run**: Every deployment, every build

| # | Test | Steps | Expected | Priority |
|---|---|---|---|---|
| 1 | App loads | Open homepage | Page loads <3s, no errors | P0 |
| 2 | Login works | Login with valid creds | Dashboard displayed | P0 |
| 3 | Core feature works | [Primary user action] | [Expected result] | P0 |
| 4 | Logout works | Click logout | Redirected to login | P0 |
```

### Full Regression (2-4 hours)

Comprehensive test execution covering all features.

### Targeted Regression (30-60 min)

Tests focused on areas affected by a specific change.

### Execution Order

```
1. Smoke tests (stop if any fail)
2. Authentication & authorization
3. Core business flows
4. Integration points
5. Edge cases & boundary values
6. UI/UX validation
7. Performance checks
```

## 4. Figma Design Validation

Compare implementation against Figma designs component by component.

### Validation Checklist

```markdown
## Design Validation: {Page/Component Name}

**Figma**: [Figma URL]
**Implementation**: [Staging URL]

### Layout
- [ ] Component positioning matches design
- [ ] Spacing between elements matches (check padding/margin)
- [ ] Responsive breakpoints match design specs

### Typography
- [ ] Font family correct
- [ ] Font sizes match at all breakpoints
- [ ] Font weights match
- [ ] Line heights match
- [ ] Letter spacing matches

### Colors
- [ ] Background colors match
- [ ] Text colors match
- [ ] Border colors match
- [ ] Hover/active state colors match

### Interactive States
- [ ] Default state matches
- [ ] Hover state matches
- [ ] Active/pressed state matches
- [ ] Focus state matches (keyboard)
- [ ] Disabled state matches
- [ ] Loading state matches
- [ ] Error state matches
- [ ] Empty state matches

### Assets
- [ ] Icons correct and sized properly
- [ ] Images have correct aspect ratios
- [ ] SVGs render correctly
```

## 5. Bug Reports

### Structure

```markdown
## BUG-{ID}: {Specific title describing the issue}

**Severity**: P0 (Blocker) / P1 (Critical) / P2 (Major) / P3 (Minor)
**Component**: {Affected component/module}
**Environment**: {Browser, OS, device, staging/prod}
**Reporter**: {Name}
**Date**: {YYYY-MM-DD}

### Description
{One sentence describing the bug}

### Steps to Reproduce
1. {Exact step}
2. {Exact step}
3. {Exact step}

### Expected Result
{What should happen}

### Actual Result
{What actually happens}

### Evidence
- Screenshot: {link}
- Console errors: {paste}
- Network requests: {relevant details}

### Workaround
{If known, describe workaround}

### Additional Context
{Browser console errors, related tickets, recent changes}
```

### Severity Guide

| Severity | Impact | Example |
|---|---|---|
| **P0 - Blocker** | System unusable, data loss | App crashes on login |
| **P1 - Critical** | Major feature broken, no workaround | Cannot submit payment |
| **P2 - Major** | Feature broken but workaround exists | Search filters don't clear (can refresh) |
| **P3 - Minor** | Cosmetic or minor inconvenience | Button slightly misaligned |

## Anti-Patterns

| Avoid | Why | Instead |
|---|---|---|
| Vague test steps | Can't reproduce | Specific actions with expected results |
| Missing preconditions | Tests fail unexpectedly | Document all setup requirements |
| No test data | Tester blocked | Provide sample data or generation steps |
| Generic bug titles | Hard to track and deduplicate | Specific: "[Feature] fails when [action]" |
| Skipping edge cases | Miss critical bugs | Include boundary values, nulls, empty strings |
| No exit criteria | Testing never "done" | Define measurable completion criteria |

## Verification Checklist

**Test Plan:**
- [ ] Scope clearly defined (in/out)
- [ ] Entry/exit criteria specified
- [ ] Risks identified with mitigations
- [ ] Timeline realistic

**Test Cases:**
- [ ] Each step has expected result
- [ ] Preconditions documented
- [ ] Test data available
- [ ] Priority assigned

**Bug Reports:**
- [ ] Reproducible steps (tested twice)
- [ ] Environment documented
- [ ] Evidence attached
- [ ] Severity/priority set

## References

- Based on [softaworks/agent-toolkit qa-test-planner](https://github.com/softaworks/agent-toolkit/tree/main/skills/qa-test-planner) (MIT License)

<!-- Source: .faos/custom/skills/testing/qa-test-planner/SKILL.md -->