Testing Strategy: Quality Assurance Architecture & Automation Design

Generic, brand-neutral engineering capability; deep, sourced playbooks live in references/ and knowledge/. [DOC]

Generic, brand-neutral engineering capability; sourced playbooks in references//knowledge/. [DOC]

TL;DR

Testing strategy defines how quality is verified, automated, and measured across the software delivery lifecycle. The skill produces comprehensive test architectures covering shape selection, automation frameworks, contract testing, performance and chaos testing, test data management, and quality metrics that shift quality left while maintaining production confidence [EXPLICIT]

When to Use

• Designing test strategy for new projects or test infrastructure overhaul
• Establishing test automation frameworks and CI integration
• Implementing contract testing for microservices or API consumers
• Introducing performance testing and chaos engineering practices
• Building test data management and environment strategies
• Defining quality metrics, coverage targets, and quality gates
• Reducing flaky tests and improving test suite reliability

When NOT to Use

• Application code architecture and design patterns
• CI/CD pipeline design and deployment automation
• Production monitoring and incident response
• Load testing and capacity planning as primary focus

---

Sub-capabilities (resource map)

Deep, evidence-tagged playbooks — open the one the task needs (ICM Layer 3, on-demand). [INFERENCE]

Procedure

1. Resolve the sub-capability; open the matching references/ playbook. [EXPLICIT]
2. Apply its decision tables; pick the strategy explicitly. [EXPLICIT]
3. Validate against the Quality Criteria and tag every claim. [EXPLICIT]

Quality Criteria

• Sub-capability resolved to one playbook. [INFERENCE]
• Claims evidence-tagged. [EXPLICIT]

Contract

• Aceptación: capability resolved to its reference playbook, applied, validated, evidence-tagged. [EXPLICIT]
• Límites: · Does not design application architecture · Does not build CI/CD pipelines · Does not monitor production systems · Coverage numbers alone do not guarantee quality; test quality ma. [EXPLICIT]
• Casos borde: Greenfield Project: Start with unit test framework from day one. Add integration tests as external dependencies emerge. Defer E2E until user journeys stabilize. Establish conve. [EXPLICIT]
• Supuestos: · Codebase is under version control with CI/CD pipeline available · Team has testing experience or is willing to invest in upskilling · Test environments can be provisioned (local,. [SUPUESTO]
• Trade-off: Decision Enables Constrains When to Use --- --- --- --- Heavy unit testing Fast feedback, cheap maintenance Misses integration issues Business logic-heavy,. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · assets/ recursos estáticos.