Metrics and queries for testing
Metrics and queries for testing
| Metric | Signals |
|---|---|
| Pass rate | Overall suite health |
| Flaky test rate | Whether a red build is believable |
| Test duration | Feedback speed |
| Coverage of changed code | Whether new work is tested |
| Failures by area | Where quality is weakest |
Flakiness dominates
A suite with a 99% pass rate and 4% flakiness is not 99% healthy — the flakiness makes every failure ambiguous, so the team re-runs rather than investigates, and genuine regressions are retried away. This is why flaky test rate belongs on the dashboard next to pass rate rather than buried.
Duration and behaviour
Test duration is a behavioural metric. Once a suite is slow enough, people stop running it locally and batch changes to avoid waiting — which increases the size of each change and makes failures harder to attribute.
Coverage, carefully
Report coverage of the code a change touched, not the repository-wide figure. Coverage measures which lines executed, never whether anything was asserted, so a global percentage is a weak quality proxy and a poor target. Coverage of changed code is actionable and cannot be satisfied by writing tests somewhere else.
Queries worth having
Failures grouped by area path tell you where quality is weakest — but only if test results are actually published, which returns to the same requirement: no publish step, no data.
Primary sources