Comprehensive QA engineering toolkit for creating test plans, generating manual test cases, building regression suites, validating designs, and documenting bugs.
Scanned 6/6/2026
Install via CLI
openskills install frank-luongt/faos-skills-marketplace<!-- 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.
tags: [qa, test-plan, regression, manual-testing, bug-report]
---
# 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 -->
No comments yet. Be the first to comment!