I would start the explanation with the point that, when it comes to unit testing, code coverage doesn't even help us have protection against regression bugs, which is a fundamental flaw... because if we're not protected against regression bugs, we don't have assurance that the software keeps on working as expected. You can show managers the examples I've shown in this article https://journal.optivem.com/p/100-code-coverage-but-0-bug-protection
Taking a big picture view, above I talked about just *one* quality characteristic - Functional Suitability - because many companies are failing right there. However, once you've achieved that quality characteristic, you need to communicate to your managers the other characteristics too https://journal.optivem.com/p/software-product-quality
When you keep getting pressure to hit coverage numbers - how do you explain to managers that it’s not the same as quality?
I would start the explanation with the point that, when it comes to unit testing, code coverage doesn't even help us have protection against regression bugs, which is a fundamental flaw... because if we're not protected against regression bugs, we don't have assurance that the software keeps on working as expected. You can show managers the examples I've shown in this article https://journal.optivem.com/p/100-code-coverage-but-0-bug-protection
But on top of that, even if we have high mutation code coverage, it doesn't assure us that the software works correctly from the user perspective. That's why we need Acceptance Tests too https://journal.optivem.com/p/from-unit-tests-to-acceptance-tests-why-i-shifted-my-focus
Taking a big picture view, above I talked about just *one* quality characteristic - Functional Suitability - because many companies are failing right there. However, once you've achieved that quality characteristic, you need to communicate to your managers the other characteristics too https://journal.optivem.com/p/software-product-quality