Four Things that Turn a Coverage Number into a Release Decision

Every release review has a coverage number in it, and it's usually going up, and people read that as progress. However, what the number can't tell you is whether the code you tested is the code that mattered, and that's the part that decides whether a release is actually safe.

A percentage counts every untested line the same, so the getter nobody thinks about weighs as much as the fault handler that could bring the system down, and that's how a team lands at 90% while the one function that turns a defect into a field failure, a recall, or a warranty claim sits untested. The number went up, but the risk stayed where it was.

Four things change that, and each one moves coverage closer to a decision you can actually make.

1. Rank by risk, not by the average

The useful question isn't how much of the code is covered, but which of the uncovered part can actually hurt you. A risk metric like CRAP (Change Risk Anti-Patterns) answers it by weighing each function's complexity against its coverage.

• It finds the dangerous gaps. The functions that are both complex and barely tested rise to the top, because those are the ones that fail in the field.
• It spends effort where it pays. Testing follows risk instead of line count, so you stop closing gaps in code that could never hurt anyone.
• It gives managers something to act on. You're at 70% either way, but now you know which 30% deserves attention, which is a number you can defend in a release review.

Blog: How to Stop Writing Tests for the Wrong Functions and Start Testing with Ranked Lists by Risk

Read Now

2. Produce evidence, not just a percentage

In a regulated market the standard already names the metric it wants, and a percentage isn't it. A dashboard number won't satisfy an auditor, and turning coverage into accepted evidence is where certification time is won or lost.

• Match the metric to the standard. ISO 26262 ASIL C/D and DO-178C Level A/B expect MC/DC; IEC 61508 expects it on critical paths at SIL 3 and 4; IEC 62304 Class B and C expect traceable statement and branch evidence.
• Cut audit prep from weeks to days. Evidence produced per function, with each line traced to the test that covered it, replaces the manual scramble before every audit.
• Skip a qualification cycle. A tool already certified by an authority like TÜV can be used by your safety team without re-qualifying it, which is real schedule saved on an ASIL D or SIL 4 program.

3. Measure where the code actually runs

Coverage only means something if it reflects the system you release, and your code rarely runs on the machine that builds it. Two situations quietly break most tooling, and both carry a business cost.

• Real targets, not approximations. Firmware on a constrained target such as TriCore, PowerPC, ARM, or RISC-V needs coverage measured on the device itself, or host-based when you'd rather not depend on hardware early. Anything less measures an approximation of what you release.
• Outsourced testing without exposing source. When testing moves to a subcontractor or a separate site, coverage data that flows back and merges centrally without anyone touching your source protects the IP and still gives you the evidence. On an IP-sensitive program, that often decides the whole tooling choice.

4. Close the gap with AI, under review

Finding the risky code was always the easy half. Closing it meant writing every missing case by hand, and that only gets heavier as AI writes more of the code arriving in the repo. The shift is to point that same AI at the gap.

• AI writes the missing tests. Given real coverage data over a protocol like MCP, an agent reads what's been exercised, writes the tests that fill the gaps, and re-checks its own work by running coverage again.
• A human still signs off. The agent targets the exact untested lines instead of guessing, and a tester approves every case before it counts, so the bar stays the same whether a person or a model wrote the code.
• Only re-test what changed. Patch analysis looks at the diff, so an untested change is caught before it merges and CI stops rebuilding everything on every commit.

What this adds up to

Put the four together and coverage stops being a figure creeping up a dashboard and starts answering the only question that matters at release: are you ready? You move faster without taking on more risk, spend less on verification, walk into the audit with the evidence already written, and find the defects before your customers do. The percentage was never the goal.

Watch the Demo: How to Explore Code Coverage with AI - Find Risky Code in Minutes

The 40-minute session with Marius Schmidt of Qt Group is where you watch all four run on real code with Coco:

• Sorting a live project by CRAP to surface the riskiest functions
• Seeing a line that passes every other check fail MC/DC
• Handing a coverage report to an AI agent to close the gaps and re-verify

▶ Watch the full webinar