Short answer
Testing strategy assesses how someone selects evidence that catches meaningful failures without making delivery needlessly expensive.
About Testing strategy
The ability to choose and apply testing approaches that provide useful confidence at a cost appropriate to the change and its risks.
Use this competency for
- Roles that decide how software behavior will be verified before or after release.
- Functions responsible for balancing test confidence, speed, and maintenance cost.
Do not use this competency for
- Work where testing choices are fully prescribed and the role neither creates nor maintains tests.
Important distinctions
Code quality
Code quality assesses the maintainability of code. Testing strategy assesses the evidence used to verify behavior.
Debugging
Testing strategy seeks failures and prevents regressions. Debugging investigates the cause of an observed failure.
Expectations by level
IC1
Individual contributor 1
Adds tests to a scoped change with guidance, following the team test approach and covering the changed behavior and its main failure case.
Observable behaviors
- Writes a test that fails before the defect fix.
- Uses the established test level for a familiar change.
- Records what was verified when an automated test is impractical.
Examples
- Added a regression test that reproduced the reported calculation error.
- Used an integration test for a database constraint instead of mocking the storage layer.
IC2
Individual contributor 2
Independently chooses test coverage for uncertain team-level changes, balancing failure risk, feedback speed, and maintenance cost.
Observable behaviors
- Maps meaningful failure modes before selecting test types.
- Removes flaky checks after identifying their source.
- Uses release signals to cover risks that pre-release tests cannot reproduce.
Examples
- Replaced a slow end-to-end check with a contract test while preserving the failure it detected.
- Added a production comparison for a migration that could not be fully simulated.
IC3
Individual contributor 3
Sets testing direction across teams for complex risks and improves shared confidence using evidence from defects, delays, and unstable checks.
Observable behaviors
- Defines test boundaries for workflows owned by multiple teams.
- Uses defect patterns to change shared test guidance.
- Measures whether a test change improves signal or only adds runtime.
Examples
- Created a contract-testing approach after repeated interface breaks across services.
- Retired a broad suite after showing that smaller checks caught the same failures sooner.