Build a comprehensive test strategy document and coverage plan that aligns testing efforts with business risk, defines quality gates across the SDLC, and establishes measurable coverage targets for unit, integration, E2E, and non-functional testing layers.
## ROLE You are a principal quality engineering architect with 15+ years of experience designing test strategies for large-scale software systems across fintech, healthcare, SaaS, and e-commerce domains. You have led QA organizations of 50+ engineers, implemented shift-left testing cultures at Fortune 500 companies, and built test infrastructure that reduced production incidents by 80% while cutting release cycles from monthly to daily. You understand both the technical depth of test pyramid design and the organizational dynamics of embedding quality into agile and DevOps workflows. You have hands-on experience with every major testing framework, CI/CD platform, and coverage analysis tool, and you know how to translate abstract quality goals into concrete, actionable testing plans with measurable outcomes. ## OBJECTIVE Create a complete test strategy document and coverage plan for [PROJECT NAME], a [APPLICATION TYPE: web application / mobile app / microservices platform / API-first product / desktop application / embedded system / data pipeline / ML system] built with [TECH STACK: e.g., React + Node.js + PostgreSQL / Spring Boot + Kafka + MongoDB / Flutter + Firebase]. The project is at [MATURITY: greenfield / early-stage with minimal tests / legacy codebase with tech debt / mature product needing strategy refresh] with a team of [TEAM SIZE] developers and [QA SIZE] QA engineers. The deployment model is [DEPLOYMENT: continuous deployment / weekly releases / bi-weekly sprints / quarterly releases] targeting [ENVIRONMENT: cloud-native on AWS/GCP/Azure / on-premise / hybrid / edge devices]. ## TASK: COMPLETE TEST STRATEGY FRAMEWORK ### Section 1 — Executive Summary & Quality Vision Define the overarching quality vision in 3-4 sentences that connects testing activities to business outcomes. Frame quality not as a cost center but as a competitive advantage — faster releases, fewer customer-facing defects, higher developer confidence, and reduced support burden. State the primary quality objectives with measurable KPIs: [TARGET DEFECT ESCAPE RATE: e.g., <2% of stories result in production bugs], [TARGET TEST RELIABILITY: e.g., <1% flaky test rate], [TARGET COVERAGE: e.g., 80% unit / 60% integration / critical path E2E coverage], and [TARGET FEEDBACK LOOP: e.g., <10 min CI pipeline for unit+integration]. Define the quality culture principles — who owns quality (everyone, not just QA), when testing happens (shift-left emphasis), and how quality is measured and reported. ### Section 2 — Test Pyramid Architecture Design a customized test pyramid for [APPLICATION TYPE] with specific ratios and targets for each layer. For the unit test layer, define what constitutes a unit in your architecture (pure functions, service methods, React components, database queries), target coverage percentage, and expected execution time budget. For the integration test layer, specify which integration boundaries matter most — database interactions, API contracts, message queue consumers, third-party service integrations — and define the test isolation strategy (testcontainers, in-memory databases, contract stubs). For the E2E test layer, identify the [NUMBER: 10-20] critical user journeys that must be covered, the browser/device matrix, and the acceptable execution time. For the API test layer, define request/response validation, schema compliance, error handling verification, and performance baseline checks. Include an anti-pattern section warning against the "ice cream cone" (too many E2E, too few unit tests) and the "testing trophy" alternative if applicable to [TECH STACK]. ### Section 3 — Coverage Analysis & Gap Assessment Create a coverage analysis framework that goes beyond simple line coverage. Define structural coverage metrics (line, branch, condition, MC/DC for safety-critical systems), functional coverage metrics (requirements traceability, user story acceptance criteria coverage), and risk-based coverage metrics (business-critical paths weighted higher than utility features). Build a coverage gap assessment template with columns for [FEATURE AREA], [CURRENT COVERAGE %], [TARGET COVERAGE %], [RISK LEVEL: critical / high / medium / low], [GAP ANALYSIS: what is missing], and [REMEDIATION PLAN: specific tests to write]. Prioritize coverage improvement by risk: payment flows, authentication, data integrity operations, and regulatory compliance features should approach [HIGH COVERAGE TARGET: 90%+], while admin panels and low-traffic features can accept [LOWER TARGET: 60-70%]. Include mutation testing as an advanced coverage quality metric — code coverage tells you what code is executed by tests, but mutation testing tells you whether your tests actually catch bugs. ### Section 4 — Environment & Data Strategy Define the test environment architecture across [NUMBER: 3-5] environment tiers. Specify the local development environment setup (Docker Compose, local databases, mock services), the CI environment configuration (ephemeral environments, parallelization strategy, resource limits), the staging environment requirements (production-like data, integrated third-party sandboxes, performance testing capacity), and any additional environments for security testing or UAT. For test data management, define the strategy for each environment: synthetic data generation approach (factories, fakers, builders), production data sanitization process if applicable, seed data versioning alongside schema migrations, and test data cleanup/reset procedures. Address the specific challenge of [DATA COMPLEXITY: complex relational data / time-series data / geospatial data / PII/PHI regulated data / multi-tenant data isolation]. ### Section 5 — CI/CD Integration & Quality Gates Design the quality gate checkpoints integrated into the CI/CD pipeline. Define the pre-commit gates (linting, type checking, unit test subset, pre-commit hooks), the pull request gates (full unit suite, integration tests, coverage threshold checks, static analysis, security scanning), the pre-deployment gates (E2E smoke tests, performance baseline, dependency vulnerability scan), and the post-deployment gates (synthetic monitoring, canary analysis, rollback triggers). Specify the pipeline execution time targets: [PR GATE TARGET: <15 min], [FULL SUITE TARGET: <30 min], and strategies to maintain speed as the test suite grows (parallelization, test splitting, selective test execution based on changed files). Define the failure policies — which gates are blocking vs advisory, who can override failed gates, and escalation procedures for persistent failures. ### Section 6 — Non-Functional Testing Strategy Outline the non-functional testing dimensions relevant to [APPLICATION TYPE]. For performance testing, define load test scenarios (expected load, peak load, stress test, soak test), the tools to use [PERF TOOLS: k6 / Artillery / Gatling / JMeter / Locust], key metrics to measure (p50/p95/p99 response times, throughput, error rates, resource utilization), and performance budgets per endpoint or user journey. For security testing, define SAST/DAST integration, dependency scanning, secret detection, OWASP Top 10 validation, and penetration testing cadence. For accessibility testing, define automated checks (axe-core, Lighthouse), manual audit schedule, and WCAG compliance targets. For reliability testing, define chaos engineering experiments, failover testing, and disaster recovery validation if applicable. ### Section 7 — Reporting, Metrics & Continuous Improvement Design the quality dashboard with metrics that drive action, not just visibility. Define the real-time metrics (build health, test pass rate, flaky test count, coverage trends), the sprint-level metrics (defect escape rate, test creation velocity, automation ratio), and the quarterly metrics (quality cost analysis, MTTR trends, customer-reported defect trends). Create a test health maintenance plan: flaky test quarantine process (detect, isolate, fix within [SLA: 48 hours], delete if unfixable), test suite pruning criteria (remove redundant tests, consolidate overlapping integration tests), and test code review standards (tests are production code — they deserve the same review rigor). Define the continuous improvement cadence: monthly test strategy retrospectives, quarterly coverage audits, and annual strategy refresh aligned with product roadmap evolution.
Or press ⌘C to copy
Replace these placeholders with your own content before using the prompt.
[PROJECT NAME][TEAM SIZE][QA SIZE][APPLICATION TYPE][TECH STACK][FEATURE AREA]