Quality Engineering: Strategic Quality Architecture & Shift-Left Practices

The user provides a system or project name as $ARGUMENTS. Parse $1 as the system/project name used throughout all output artifacts.

Parameters:

• {MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
  • piloto-auto: Auto para maturity assessment y test strategy, HITL para quality gates y automation decisions.
  • desatendido: Cero interrupciones. Framework completo con supuestos documentados.
  • supervisado: Autónomo con checkpoint en gate criteria y automation architecture.
  • paso-a-paso: Confirma cada maturity score, test shape, gate criteria, y metric target.
• {FORMATO}: markdown (default) | html | dual
• {VARIANTE}: ejecutiva (~40% — S1 maturity + S4 gates + S5 metrics) | técnica (full 6 sections, default)

Before generating framework, detect the codebase context:

!find . -name "*.test.*" -o -name "*.spec.*" -o -name "*test*" -type d -o -name "jest*" -o -name "pytest*" | head -20

Use detected testing frameworks, languages, and existing test structure to tailor recommendations.

If reference materials exist, load them:

Read ${CLAUDE_SKILL_DIR}/references/quality-patterns.md

When to Use

• Designing quality strategy for new projects or quality infrastructure overhaul
• Assessing quality maturity and building improvement roadmaps
• Establishing test automation architecture and CI/CD quality gates
• Defining quality metrics, coverage targets, and dashboard design
• Introducing shift-left practices across development teams

When NOT to Use

• Writing test code or test suites → development team responsibility
• CI/CD pipeline design and deployment automation → metodologia-devsecops-architecture
• Production monitoring and incident response → metodologia-observability
• Application architecture and design patterns → metodologia-software-architecture

Delivery Structure: 6 Sections

S1: Quality Maturity Assessment

5-Level Model

Assessment Dimensions (score 0-100% each)

1. Test Strategy & Planning — formal strategy documented? pyramid/diamond defined? ownership clear?
2. Test Automation — framework selected? patterns in place? execution speed acceptable?
3. Quality Gates & CI/CD — commit/PR/release gates automated?
4. Test Data Management — synthetic generation? masking? versioning?
5. Quality Metrics & Dashboards — leading+lagging collected? dashboards shared? actions taken?
6. Shift-Left Practices — developers write unit tests? code review includes quality? pre-commit hooks?

Output: Current score (1-5) overall + per dimension, target maturity (12-month), gap analysis, DORA benchmark comparison, quick wins + long-term improvements.

S2: Test Strategy

Architecture-Driven Shape

Monolith → Test Pyramid: Unit 55% | Integration 25% | API 15% | E2E 5% Microservices → Test Diamond: Unit 20% | Integration 40% | Contract 30% | E2E 10%

Test Types Summary

Test Data Strategy

• Synthetic generation: Data factories (Builder pattern, Faker). Never hardcode. Version alongside code.
• Masking (regulated): PII → fake values. PCI → last 4 digits. Healthcare → encrypt or exclude.
• Management: Dedicated test DB. Tag snapshots for reproducibility. Reset between tests.

For framework recommendations by language and automation patterns (Page Object, Screenplay, Test Data Factory, Golden Master, Testcontainers), read: ${CLAUDE_SKILL_DIR}/references/automation-patterns.md

S3: Automation Architecture

Framework Selection Criteria

Evaluate: language alignment, team skills, community support, maintenance cost, scalability, reporting, cost (OSS vs commercial).

CI/CD Pipeline Stages

For detailed pipeline YAML examples and report/dashboard architecture, read: ${CLAUDE_SKILL_DIR}/references/pipeline-stages.md

S4: Quality Gates

Gate Enforcement Rules

• Blocking: Commit, PR, Release gates block deployment
• Async: Nightly gate alerts but requires manual decision
• No bypass: Security gates (SAST, DAST) cannot be bypassed
• Bypass audit: Any bypass logged with reason and approver
• Timeout policy: Exceeding timeout = fail the gate
• Flaky tests: Failing >2x/week → remove from gate, refactor separately

Gate Pass Criteria

S5: Quality Metrics

Leading Indicators (predict future quality)

Lagging Indicators (measure past quality)

Dashboard Design

4 panels: Test Health (pass/fail, execution time, flaky list, coverage trend), Quality Metrics (DORA, incidents, escaped defects), Automation Coverage (by type and team), SLA Compliance (build stability, PR pass rate, deploy success).

S6: Implementation Plan

Assumptions & Limits

• Quality engineering designs; QA executes. This outputs strategy, not test suites.
• Automation ROI requires 3-4 execution cycles. Do not automate one-off tests.
• Shift-left requires developer buy-in for unit tests and pre-commit gates.
• Production-like environments required for reliable performance testing.
• Cannot guarantee zero defects — goal is risk-appropriate quality investment.
• Exploratory testing finds bugs automation misses; budget 25-30% for it.

Edge Cases & Adaptations

Trade-off Matrix

Conditional Logic

IF deployment frequency > 1/day → full CI/CD with automated gates; no manual gates in critical path; feature flags required
IF financial/healthcare/PCI → add data integrity, encryption, audit trail, PII masking tests; mandatory pen testing
IF team has no automation experience → 4-6 week ramp-up; start with API-level; avoid UI frameworks initially
IF performance SLA exists → add perf regression to CI; baseline in staging; alerts on PR threshold violations
IF multiple teams → consumer-driven contract testing; shared test data contracts; monthly contract reviews
IF legacy with no tests → characterization tests first; NEVER refactor without tests

Casos Borde

Decisiones y Trade-offs

Knowledge Graph

graph TD
    subgraph Core["Core: Quality Engineering"]
        MAT[Quality Maturity Assessment]
        TS[Test Strategy]
        AA[Automation Architecture]
        QG[Quality Gates]
        QM[Quality Metrics]
        IP[Implementation Plan]
    end

    subgraph Inputs["Inputs"]
        ARCH[Architecture Type]
        CODE[Codebase & Test Infra]
        REQ[Quality Requirements]
        TEAM[Team Skills]
    end

    subgraph Outputs["Outputs"]
        FRAME[Quality Framework Doc]
        SCORE[Maturity Scorecard]
        GATES[Gate Criteria Checklist]
        DASH[Metrics Dashboard]
    end

    subgraph Related["Related Skills"]
        DSO[devsecops-architecture]
        SWA[software-architecture]
        OBS[observability]
        TEST[testing-strategy]
    end

    ARCH --> TS
    CODE --> MAT
    REQ --> QG
    TEAM --> AA
    MAT --> TS --> AA --> QG --> QM --> IP
    IP --> FRAME
    IP --> SCORE
    IP --> GATES
    IP --> DASH
    FRAME --> DSO
    FRAME --> SWA
    DASH --> OBS
    TS --> TEST

Output Templates

Evaluacion

Umbral minimo: 7/10.

Validation Gate

Before delivering quality engineering output:

• Architecture type identified (monolith/microservices/hybrid) and test shape matched
• All 5 pipeline stages have defined pass criteria and timeouts
• Metrics include both leading and lagging indicators with targets
• Edge cases addressed for the client's specific context
• Implementation plan is phased with realistic effort estimates
• Regulatory requirements (if any) explicitly layered in

Cross-References

• metodologia-testing-strategy: Detailed test architecture — pyramid, automation, contract testing, chaos engineering
• metodologia-devsecops-architecture: CI/CD pipeline design where quality gates are enforced
• metodologia-observability: Production monitoring that validates quality in production
• metodologia-software-architecture: Internal system structure that quality engineering validates

Output Format Protocol

Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.

Output Artifact

Primary: A-01_Quality_Engineering.html — Maturity assessment, test strategy, automation architecture, quality gates, metrics dashboard, implementation plan.

Secondary: Quality maturity scorecard, gate criteria checklist, metrics dashboard template, implementation timeline.

Autor: Javier Montaño | Última actualización: 12 de marzo de 2026