test-strategy

Generates a test strategy document defining pyramid distribution, coverage targets, and tooling per layer.

Updated Sep 10, 2026
One-click install
npx skills add https://github.com/serpro-workshop-fortaleza/datacorp-sifap-modernization-team-kit --skill test-strategy-serpro-workshop-fortaleza
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-strategy
Source: https://github.com/serpro-workshop-fortaleza/datacorp-sifap-modernization-team-kit/tree/main/.github/skills/test-strategy
Command: npx skills add https://github.com/serpro-workshop-fortaleza/datacorp-sifap-modernization-team-kit --skill test-strategy-serpro-workshop-fortaleza

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often lack a coherent test strategy, ending up with inverted test pyramids, arbitrary coverage numbers, and flaky E2E suites. This Skill guides the creation of a one-page test strategy with risk-based coverage targets, layer-specific tooling, and quarantine rules. ## Core Features & Use Cases - Risk-Based Planning: Classifies modules as P0/P1/P2 by failure blast radius and assigns differentiated coverage targets (80% baseline, 90% for P0). - Pyramid Distribution: Applies a 70/20/10 unit/integration/E2E baseline with justified deviations, plus a flaky-test budget of 1% with quarantine rules. - Tooling Selection: Recommends tools per layer such as JUnit 5, Vitest, Testcontainers, and Playwright. - Use Case: When modernizing a legacy system, ask for a test strategy audit to get a structured document with per-layer targets, tools, and quality gates. ## Quick Start Ask the AI to elaborate a test strategy for your system or module, including pyramid distribution, coverage targets, and tooling per layer.

Frequently Asked Questions about test-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a test strategy for a software project?▼

Start by inventorying tested code, classifying modules by risk (P0/P1/P2), then distributing tests across a 70/20/10 unit/integration/E2E pyramid. Set coverage targets per risk level and define tooling and quarantine rules for each layer.

What is the ideal ratio of unit, integration, and E2E tests?▼

A common baseline is 70% unit, 20% integration, and 10% E2E tests. Deviations are acceptable when justified, but an inverted pyramid with many slow E2E tests over few unit tests is an antipattern.

What test coverage percentage should I target?▼

Use 80% line coverage as a baseline and 90% for P0 (highest-risk) modules, tracking branch coverage separately. Avoid a single global coverage number without higher targets for critical modules.

Which tools should I use for each test layer?▼

Use Vitest, JUnit, or pytest for unit tests, Testcontainers for integration tests, and Playwright for E2E tests. Contract tests are preferred over mocks for anything crossing service boundaries.

How do I handle flaky tests in a test suite?▼

Set a flaky-test budget of at most 1% of the suite. Any rate above that threshold triggers quarantine, isolating unstable tests until they are fixed or removed.

When should I rewrite E2E tests as integration tests?▼

Rewrite an E2E test as integration and contract tests whenever possible, since E2E tests are expensive and unstable. Mutation testing tools like Stryker or PIT can also reveal tests that prove nothing.