
Generate Testing Strategy
- 1 installs
- Updated May 2, 2026
- eroveda/blueprint-skills
Generate a consolidated TESTING_STRATEGY.md that aggregates acceptance criteria from executable specs into unit, integration, E2E, and non-functional levels.
About
Reads executable specs and synthesizes a TESTING_STRATEGY.md covering four test levels, test data strategy, CI/CD integration, and a spec-to-test verification matrix. A developer uses it after specs are generated to plan the testing phase.
- Categorizes tests into unit, integration, E2E, and non-functional levels
- Builds a verification matrix mapping each spec to its tests and flags gaps
Generate Testing Strategy by the numbers
- 1 all-time installs (skills.sh)
- Ranked #1,750 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Jul 8, 2026 (Skillselion catalog sync)
npx skills add https://github.com/eroveda/blueprint-skills --skill generate-testing-strategyAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| Last updated | May 2, 2026 |
| Repository | eroveda/blueprint-skills ↗ |
What it does
Generate a consolidated TESTING_STRATEGY.md that aggregates acceptance criteria from executable specs into unit, integration, E2E, and non-functional levels.
Files
Generate Testing Strategy
This skill produces TESTING_STRATEGY.md — a consolidated testing approach extracted and synthesized from all executable specs.
Approach
1. Read the source specs:
- If
03-SPECS.yamlexists → parse the single file - If
specs/directory exists → read all spec files
2. For each spec, extract:
- Acceptance criteria
- Verification command
- Category (TESTING specs get special treatment)
- Dependencies (to identify integration boundaries)
3. Categorize tests into 4 levels:
- Unit tests: from acceptance_criteria of CONSTRUCTION specs
- Integration tests: from specs marked TESTING + cross-spec acceptance
- End-to-end tests: complete user flows
- Non-functional tests: load, security, accessibility, performance
4. Generate TESTING_STRATEGY.md with structure below.
Output
You MUST save the strategy as a file.
Filename: TESTING_STRATEGY.md (exact name, uppercase, with underscore) Format: Markdown Location: Project root directory (cwd)
The file MUST contain these sections:
Testing Philosophy
- Approach (TDD, BDD, etc.)
- Coverage targets
- Tools and frameworks recommended (per the tech stack in ARCHITECTURE.md)
Test Levels
1. Unit Tests
- Scope: individual functions, classes, modules
- Coverage target: 80%+ on business logic
- Tools: based on tech stack
- Source: acceptance criteria from CONSTRUCTION specs
- List: enumerate which specs contribute unit tests
2. Integration Tests
- Scope: interactions between modules, database access, external APIs
- Coverage target: critical paths (100%)
- Tools: based on tech stack
- Source: specs marked TESTING + cross-spec dependencies
3. End-to-End Tests
- Scope: complete user journeys
- Coverage target: top 5 user flows
- Tools: Playwright, Cypress, etc. (based on stack)
- Source: extracted from FUNCTIONAL_FLOWS.md flows
4. Non-Functional Tests
- Performance/Load (NFRs from ARCHITECTURE.md)
- Security (penetration, OWASP Top 10)
- Accessibility (WCAG 2.1 if applicable)
- Compatibility (browsers, devices)
Test Data Strategy
- Fixtures vs factories vs seeds
- Test database approach
- Mocking external services
CI/CD Integration
- Where each test level runs (PR, main, nightly)
- Failure handling
- Coverage reporting
Verification Matrix
A table mapping each spec to its tests:
| Spec ID | Spec Name | Unit | Integration | E2E | Verification Command |
|---|---|---|---|---|---|
| B1 | Bootstrap | - | ✓ | - | npm test |
| B4 | Auth | ✓ | ✓ | ✓ | npm test:auth |
Risks and Gaps
- Specs without acceptance criteria
- Integration boundaries not covered
- External dependencies that need contract tests
After writing the file, confirm to the user with:
- Absolute path to TESTING_STRATEGY.md
- Total test scenarios identified
- Coverage gaps (if any)
DO NOT:
- Invent acceptance criteria not in source specs
- Recommend tools incompatible with the documented tech stack
- Skip generation if some specs lack acceptance criteria (note them as gaps)