Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
eroveda avatar

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-strategy

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
Last updatedMay 2, 2026
Repositoryeroveda/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

SKILL.mdMarkdownGitHub ↗

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.yaml exists → 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 IDSpec NameUnitIntegrationE2EVerification Command
B1Bootstrap--npm test
B4Authnpm 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)

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.