Tech Due Diligence CQ-2: Test Coverage and Testing Strategy
A test suite is useful when it gives the team dependable feedback about changes that matter. In a due diligence review, start with the product's critical behaviours: charging a customer, authorising an action, keeping tenant data separate or recovering a failed job. Ask which tests would fail if those behaviours broke.
Work through the Tech Due Diligence assessment, record supporting evidence and review the gaps in your answers.
Review objective
The assessor evaluates the breadth, depth, and effectiveness of the automated testing strategy, including unit tests, integration tests, end-to-end tests, and the overall test coverage metrics across the codebase.
In Plain Language
Line coverage can help locate untested areas, but it does not show whether assertions are meaningful or whether important integrations work. Read a sample of tests alongside the behaviour they claim to protect. Check failure cases as well as the successful path. A high aggregate figure can hide an untested payment flow or a permission boundary.
The right mix of unit, integration and end-to-end tests depends on the system. A numerical testing pyramid is not an acceptance criterion for every codebase. Look for feedback that arrives soon enough to influence a change, covers the relevant risks and can be trusted by the people shipping it.
Be explicit about review limits. A sample of a few critical flows is not a full validation of the product. Record what was examined, which environments were used and where confidence depends on statements from the team rather than observed results.
How to Implement
Choose a small set of business-critical flows with the product and engineering leads. Include permission checks, failure and retry behaviour, and boundaries between services where those affect the product. Map each flow to the tests and manual checks intended to protect it. Note any dependency that is always mocked and establish what verifies the real integration.
Inspect recent changes to those flows. Read the change, the associated tests and the CI result. Ask what failure the test would detect. Where appropriate, demonstrate that a representative defect causes the test to fail in a safe test environment. Do not treat the existence of a test file as proof that it exercises the intended behaviour.
Review how the suite is used in delivery. Check which results block merging or release, who can bypass them and whether bypasses are reviewed. Look at failed and rerun jobs, not just the last green build. Separate infrastructure failures from flaky tests and product defects so you can see whether repeated reruns are hiding a problem.
Examine test duration and maintenance. A suite that takes too long to run may be skipped; one that fails unpredictably may be ignored. Record the actual effect on the team's workflow rather than prescribing a universal duration or coverage percentage. Ask how unreliable tests are repaired and what protection exists while they are disabled.
Report gaps in terms of product risk. Name the behaviour left unverified and the consequence of a regression. Suggest a targeted next step, such as an integration test against the real storage interface or an authorisation test between tenants. State the work already planned and distinguish it from checks that run today.
Evidence to review
- Critical-flow list with the tests or manual checks covering each behaviour
- Representative tests reviewed alongside recent code changes
- CI results including failures, reruns and bypasses
- Evidence of integration checks where production dependencies are mocked elsewhere
- Known test gaps and the team's prioritised follow-up work
- Coverage reports where used, with scope and exclusions recorded
Common Mistakes
- Coverage targets reward execution without useful assertions
- Important permission or failure paths have no test
- A mocked boundary has no corresponding integration check
- Rerunning flaky jobs is the normal route to a green build
- Disabled checks have no owner or replacement protection
- A clean CI result is presented as validation of behaviour the suite never exercises
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| ISO 27001 | ISO 27001 A.8.25: Secure development life cycle | Related |
Frequently Asked Questions
What coverage percentage is good enough?
Does the team have to use TDD?
Related Articles
Track Tech Due Diligence compliance in one place
Work through the Tech Due Diligence assessment, record supporting evidence and review the gaps in your answers.
Start Free AssessmentStart without an account · Sign up only to save