Testing Strategy and Quality Management¶

Quality and development speed are connected through technical debt: poor quality = slow development. Good testing infrastructure enables faster, safer deployments.

Testing Pyramid¶

      /    E2E    \        <- Fewest, most expensive, slowest
     / Integration \       <- Middle layer
    /   Unit Tests  \      <- Most tests, cheapest, fastest

Rule: many unit tests, ~10x fewer integration, ~10x fewer E2E.

Level	What	Cost	Speed
Unit	Individual functions	Cheap	Fast
Integration	Service interactions	Moderate	Moderate
E2E	Full user flows	Expensive	Slow

Contract Testing¶

Ensures two services can interact correctly by verifying API contracts match. Critical when multiple teams own different services. Prevents breaking changes when one team modifies their API.

Workflow: service A defines expected request/response -> contract published -> service B validates against contract -> any mismatch flagged before deployment.

Chaos Engineering¶

Intentionally inject failures to test resilience. Netflix Chaos Monkey randomly kills production services.

If you're not Netflix/Google scale, you don't need it. Only relevant for massive distributed systems verifying resilience to random failures.

Types: fault injection (errors), traffic shaping (simulate conditions).

Test Design Techniques¶

Strategic selection of test cases to check maximum functionality with minimum tests: - Equivalence partitioning (one value per input class) - Boundary value analysis (edges of valid ranges) - Decision tables (combinations of conditions) - State transition testing (valid/invalid state changes)

Impact Analysis¶

When making changes, developers communicate to testers what areas are affected. Cross-team collaboration essential - testers need to understand the impact radius.

Quality + Deployment Connection¶

Contract testing + proper migration strategy + quality gates = confidence to deploy frequently.

The less obvious point: good testing infrastructure enables faster, safer deployments, not just catches bugs.

Gotchas¶

Testing pyramid inversion (many E2E, few unit tests) = slow, fragile, expensive CI
E2E tests for every feature - only critical user journeys deserve E2E. Use contract tests for service boundaries
Chaos testing without monitoring - injecting failures without observing results is just breaking things
100% code coverage doesn't mean quality - can have full coverage and miss critical edge cases