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

#	Document	File	Purpose	Audience	Phase
1	Software Test Plan	`templates/software-test-plan.md`	Testing strategy, tools, environments, schedule	QA leads, PMs, devs	After SRS + SDD
2	Test Case Specifications	`templates/test-case-specifications.md`	Detailed test steps, inputs, expected results	Test engineers, devs	During development
3	Validation & Verification Plan	`templates/validation-verification-plan.md`	V&V approach (built right + right product)	QA mgrs, PMs, compliance	After SRS + SDD
4	Validation Test Report	`templates/validation-test-report.md`	Test execution results and release decision	PMs, stakeholders, QA	Before release
5	Peer Review Report	`templates/peer-review-report.md`	Code, design, and document review findings	Dev team, tech leads	Throughout SDLC

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:

Activity	Traditional Phase	Shift-Left Phase
Unit testing	After coding	During coding (TDD)
Security testing	Pre-release	During design + development
Performance testing	Pre-release	During development (benchmarks)
Code review	After feature complete	Per-commit (PR-based)
Requirements review	After SRS finalized	During requirements gathering

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

Input	Source	Required?
Software Requirements Spec (SRS)	`sdlc-planning` output	Yes
Software Design Document (SDD)	`sdlc-design` output	Recommended
Quality Assurance Plan	`sdlc-planning` output	Recommended
Risk Management Plan	`sdlc-planning` output	Recommended
Feature specifications	`feature-planning` output	If feature-level

Testing Layers Overview

Unit Testing

Platform	Framework	Scope	Speed
Android	JUnit 5 + MockK + Turbine	ViewModels, UseCases, Repositories, Mappers	<1ms each
PHP	PHPUnit	Services, validators, business logic, helpers	<10ms each

Integration Testing

Platform	Framework	Scope
Android	Room in-memory DB + MockWebServer	DAO queries, API contracts, auth flows
PHP	PHPUnit + real MySQL test DB	API endpoints, stored procedures, multi-table ops

UI / E2E Testing

Platform	Framework	Scope
Android	Compose Testing + Espresso	Screen rendering, navigation, user flows
Web	Browser testing (manual + automated)	CRUD workflows, form validation, responsive layout

Security Testing

Area	Method	Reference
Tenant isolation	Automated + manual: cross-tenant access denied	`vibe-security-skill`
Auth bypass	Token manipulation, session hijacking attempts	`dual-auth-rbac`
Injection	SQL injection, XSS, CSRF payloads	OWASP Top 10
Data exposure	API response auditing, error message review	`vibe-security-skill`

Performance Testing

Metric	Target	Tool
API response time	< 500ms (P95)	curl timing, load test tools
Web page load	< 2s (first contentful paint)	Browser DevTools, Lighthouse
Android cold start	< 3s	Android Profiler
Database query	< 100ms (P95)	MySQL slow query log, EXPLAIN

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

Skill	Relationship
`sdlc-planning`	Provides SRS (requirement IDs for traceability), QA Plan (quality standards), Risk Plan (test-specific risks).
`sdlc-design`	Provides SDD (architecture to verify), database design (schema to test), API design (contracts to validate).
`project-requirements`	Raw requirements gathered via interview. Feed into SRS before creating test docs.

Parallel Skills (use ALONGSIDE this skill)

Skill	Relationship
`android-tdd`	Actual TDD implementation patterns (Red-Green-Refactor, layer-specific tests). This skill documents; `android-tdd` implements.
`ai-error-handling`	5-layer validation stack for AI-generated code. Complements this skill's formal V&V processes.
`ai-error-prevention`	"Trust but verify" patterns. Use alongside peer review processes.
`vibe-security-skill`	Security testing patterns, OWASP mapping. Reference in test plans and security test cases.
`feature-planning`	Feature-level testing strategy. This skill covers project-level testing.

Downstream Skills (use AFTER this skill)

Skill	Relationship
`google-play-store-review`	Play Store compliance testing. Uses test results from this skill's reports.

Sibling SDLC Skills

Skill	Phase	Status
`sdlc-planning`	Planning & Management	Available
`sdlc-design`	Design & Architecture	Available
`sdlc-testing`	Testing & Quality	This Skill
`sdlc-user-deploy`	Delivery & Deployment	Available

Adaptation Rules

SaaS vs Standalone

Aspect	Multi-Tenant SaaS	Standalone App
Tenant isolation tests	Required (franchise_id in every query)	Not applicable
RBAC test cases	Full matrix (super_admin, owner, staff)	Simple role tests
Cross-tenant security	Dedicated test suite	Omit
Test data setup	Per-tenant fixtures (franchise_id = 1, 2)	Single dataset

Android + Web vs Web-Only

Aspect	Android + Web	Web-Only
Test frameworks	JUnit 5, MockK, Compose Testing + PHPUnit	PHPUnit only
UI testing	Compose tests + browser tests	Browser tests only
Offline testing	Room caching, network error scenarios	N/A
Device matrix	API levels 26-35, multiple screen sizes	Browser matrix

CI/CD Integration

Stage	Trigger	Tests Run
Pre-commit	Local commit	Unit tests (fast)
PR validation	PR created/updated	Unit + integration tests
Merge to develop	PR merged	Full test suite + coverage
Release candidate	Tag created	Full suite + security + performance
Post-deploy	Production deploy	Smoke tests only

Quality Checklist

Anti-Patterns

Anti-Pattern	Why It Fails	Do This Instead
No formal test plan	Ad-hoc testing misses critical paths	Write STP before testing begins
Test cases without expected results	Can't determine pass/fail	Every TC has explicit expected results
No traceability to requirements	Can't prove coverage	Map every TC to FR-xxx or NFR-xxx
Testing only happy paths	Edge cases cause production failures	Include negative, boundary, and error cases
No test data strategy	Inconsistent, flaky tests	Define fixtures, factories, seed data
Skipping security testing	Vulnerabilities ship to production	Include security test suite in every release
No peer review process	Bugs caught late, inconsistent code	Standardize reviews with checklists
Rubber-stamp reviews	Reviews provide no value	Require findings documented, metrics tracked
Testing in production only	Users find bugs, not testers	Test in staging first, smoke test prod

Template Files

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

Back to: Skills Repository Related: sdlc-planning | android-tdd | vibe-security-skill | ai-error-handling Last Updated: 2026-02-20

sdlc-testing