Required Plugins

Superpowers plugin: MUST be active for all work using this skill. Use throughout the entire build pipeline — design decisions, code generation, debugging, quality checks, and any task where it offers enhanced capabilities. If superpowers provides a better way to accomplish something, prefer it over the default approach.

SDLC Testing Skill

Generate a complete Testing & Quality documentation suite for software development projects. This skill produces 5 documents that establish the testing baseline, define test cases, verify and validate the system, report results, and standardize peer reviews.

When to Use

• Establishing a testing strategy for a SaaS project
• Writing formal test plans aligned with IEEE 829
• Creating test case specifications with traceability to requirements
• Planning verification and validation activities (V&V)
• Documenting validation test results for release decisions
• Standardizing peer review and code inspection processes
• Preparing for phase gate reviews that require test evidence

When NOT to Use

• Writing actual test code (unit tests, integration tests) -- use android-tdd skill instead
• Validating AI-generated code -- use ai-error-handling skill (5-layer validation)
• Planning security testing only -- use vibe-security-skill for security patterns
• Planning a single feature -- use feature-planning skill (includes testing strategy)
• Creating project plans -- use sdlc-planning skill (SDP, QA Plan, SRS)
• Designing architecture -- use sdlc-design skill

Document Inventory

Standards Basis

This skill generates documentation compliant with BS ISO/IEC/IEEE 29119-3:2013, the current international standard for software test documentation. It supersedes IEEE 829:2008 and BS 7925-2:1998. Key structural difference: 29119-3 defines a strict document hierarchy — Organizational Test Strategy → Project Test Plan → Sub-process Test Plans → Test Design Specification → Test Case Specification → Incident Report → Test Completion Report. Annex T provides clause-level cross-walks from legacy standards for migration.

Normative Test Case Fields (BS 29119-3 §7.3): Every test case must include: (1) Unique ID, (2) Objective/Purpose, (3) Priority (H/M/L), (4) Traceability to requirement ID, (5) Preconditions (exact system state), (6) Input (exact stimulus), (7) Expected Result (deterministic pass/fail — the test oracle), (8) Actual Result (populated during execution), (9) Test Result (Pass / Incident Report number).

Test Oracle Rule: Every expected result must be specific enough to yield an unambiguous Pass or Fail without interpretation. If the expected result depends on judgment ("the response looks reasonable"), the requirement has not been adequately specified — flag [VERIFIABILITY-FAIL] and return to Skill 05 for clarification.

Testing Philosophy

TDD-First Development

All production code follows the Red-Green-Refactor cycle. Tests are written before implementation. Reference the android-tdd skill for the complete TDD workflow.

Test Pyramid (70/20/10)

        /  UI/E2E  \       10% - Compose Testing, Espresso, browser E2E
       /------------\
      / Integration  \     20% - Room+MockWebServer, API with real DB
     /----------------\
    /   Unit Tests     \   70% - JUnit 5, MockK, PHPUnit (fast, isolated)
   /====================\

Shift-Left Testing

Move testing activities as early as possible in the SDLC:

Generation Workflow

Generate documents in this order. Each builds on the previous.

Prerequisite: SRS from sdlc-planning + SDD from sdlc-design
    |
Step 1: Software Test Plan (overall strategy)
    |
Step 2: Validation & Verification Plan (V&V approach)
    |
Step 3: Test Case Specifications (detailed test cases)
    |
    [--- Development & testing execution happens here ---]
    |
Step 4: Peer Review Reports (during development)
    |
Step 5: Validation Test Report (before release)

Prerequisites

Testing Layers Overview

Unit Testing

Integration Testing

UI / E2E Testing

User Acceptance Testing (UAT)

Distinguish Alpha and Beta testing explicitly in the Test Plan:

Seven-Step Defect Resolution Protocol (Rex Black, 2009)

Every bug report triggers this handoff sequence. The boundary between Step 3 and Step 4 is the critical management line — testers own isolation; developers own debugging.

If the fix fails Step 7: reopen the bug report. If it passes but breaks a different test: open a new bug report.

Regression Testing

Regression testing is a first-class test type and must be documented separately in the Test Plan. Define: the regression suite scope (which previously-passing test cases are re-run), the trigger conditions (every PR merge, every release candidate), and the acceptable pass rate before proceeding.

Test Data Management

The Test Plan must include a ## Test Data Management section covering: how test fixtures are created, how tenant isolation is maintained in test data (separate franchise_id values per test scenario), how sensitive data is anonymized in non-production environments, and who owns test data lifecycle.

Test Data Readiness Report (B-08)

Before test execution begins, confirm:

• Test fixtures created for all scenarios (normal, boundary, error)
• Tenant isolation verified — each test scenario uses a distinct franchise_id (or equivalent)
• Sensitive production data anonymised in all non-production environments
• Test data owner identified and data lifecycle documented
• Rollback/reset procedure defined for test data after execution

Test Environment Readiness Report (B-08)

Before test execution begins, confirm:

• All hardware/software components match production specifications
• All software components under formal CM control with release notes
• Test environment access provisioned for all testers
• Monitoring and logging enabled in test environment
• Smoke test completed successfully (entry criterion for system test phase)
• Config ID documented (coded identifier for the exact environment composition)

Security Testing

Performance Testing

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

Parallel Skills (use ALONGSIDE this skill)

Downstream Skills (use AFTER this skill)

Sibling SDLC Skills

Adaptation Rules

SaaS vs Standalone

Android + Web vs Web-Only

CI/CD Integration

Quality Checklist

• All 7 documents generated (or justified why one was skipped)
• Each document stays under 500 lines
• Test Plan references SRS requirement IDs for traceability
• Test Plan includes: risk register, completion criteria, suspension/resumption criteria, communication plan, environment requirements, roles (per 29119-3 §6.2)
• Test cases use naming convention TC-[MODULE]-[TYPE]-[###]
• Every test case has the 9 normative 29119-3 fields (ID, objective, priority, traceability, preconditions, input, expected result, actual result, test result)
• Every expected result is a deterministic test oracle — no judgment calls
• Every SRS requirement ID (FR-xxx, NFR-xxx) is traced to at least one test case
• V&V Plan covers both verification (built right) and validation (right product)
• Test Plan distinguishes Alpha UAT (internal controlled) from Beta UAT (real-world users)
• Regression testing section covers: suite scope, trigger conditions, pass rate threshold
• Test Data Management section covers: fixture creation, tenant isolation, data anonymization
• Test Data Readiness Report completed before execution begins
• Test Environment Readiness Report completed before execution begins
• Test Report includes pass rates, coverage, defect resolution protocol, and Go/No-Go recommendation
• Incident Report template populated for every detected anomaly
• Test Completion Report produced at phase close: summary, deviations, residual risks, lessons learned
• Peer Review Report includes tech-stack-specific checklists
• Multi-tenant isolation addressed in test cases and V&V plan
• Test environments match deployment environments (Windows/Ubuntu/Debian)
• Security test cases reference vibe-security-skill OWASP mapping
• Performance benchmarks have numeric targets (not vague language)
• Documents cross-reference each other and upstream SRS/SDD

Anti-Patterns

Template Files

Each template provides the complete structure, section-by-section guidance, examples tailored to the tech stack, anti-patterns, and a quality checklist.

1. Software Test Plan
2. Test Case Specifications
3. Validation & Verification Plan
4. Validation Test Report
5. Peer Review / Inspection Report
6. Incident Report
7. Test Completion Report

Back to: Skills Repository Related: sdlc-planning | android-tdd | vibe-security-skill | ai-error-handling Last Updated: 2026-03-15 (upgraded to BS ISO/IEC/IEEE 29119-3:2013 per Winston, BS Standards; strengthened per Adjei 2023, Splunk Product is Docs)