A programme reports 92% Apex code coverage as evidence that a release is low-risk. How do you respond?

Carefully, because the number is not wrong — it is being asked to mean something it cannot.

Coverage measures which lines executed while tests ran. It does not measure whether anything was verified. A test that invokes a method and asserts nothing raises coverage exactly as much as one that checks every output. So a high figure is consistent with both a well-tested codebase and a codebase full of assertion-free tests written to clear a deployment gate.

The second problem is scope. Most of a Salesforce release is not Apex. Flows, validation rules, sharing configuration, integrations and the user experience carry substantial risk that Apex coverage does not touch at all.

What I offer instead is a three-part assurance picture: assertion quality in the test suite, automated regression coverage of the critical business journeys, and the defect trend from the last few releases. I keep the coverage number in the pack — it is a platform requirement and a useful floor — but I stop it being the headline.