sdlc-testing（SDLC 测试）

Platform Notes

• Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

SDLC Testing Skill

Use When

• Generate Testing & Quality documentation for SDLC projects. Compliant with BS ISO/IEC/IEEE 29119-3:2013 (supersedes IEEE 829:2008 and BS 7925-2:1998). Covers Software Test Plan, Test Case Specifications (with normative 29119-3 fields), V&V Plan...
• The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

Do Not Use When

• The task is unrelated to sdlc-testing or would be better handled by a more specific companion skill.
• The request only needs a trivial answer and none of this skill's constraints or references materially help.

Required Inputs

• Gather relevant project context, constraints, and the concrete problem to solve; load templates only as needed.
• Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

Workflow

• Read this SKILL.md first, then load only the referenced deep-dive files that are necessary for the task.
• Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
• Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

Quality Standards

• Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
• Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
• Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

Anti-Patterns

• Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
• Loading every reference file by default instead of using progressive disclosure.

Outputs

• A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
• Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
• References used, companion skills, or follow-up actions when they materially improve execution.

Evidence Produced

References

• Use the templates/ directory when the task needs a structured deliverable.

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.

Load Order

1. Load world-class-engineering.
2. Load advanced-testing-strategy.
3. Load this skill to produce formal test documentation and release evidence.

Executable Testing Standard

Testing documentation must make these explicit:

• commit-stage checks versus deeper validation
• deterministic evidence and residual risk
• telemetry that will detect escaped failure after release
• Go/No-Go inputs, rollback assumptions, and observation windows

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
• Release evidence and post-deploy watch signals are stated for risky changes
• 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

References

• ../sdlc-lifecycle.md: Shared SDLC execution model and lifecycle gates.

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)