Among the metrics for measuring code quality, there is one that is especially difficult to understand, and that is test coverage. Test coverage is a dangerous metric because a really high coverage does not imply the code is well tested. As the name says, it only contemplates whether a piece of code has been triggered and hence executed by a test. For that reason, the goal of testing is basically a combination of good tests and good coverage. To summarize, it is the quality of tests that matters, the code coverage is secondary.

There are some scenarios though where code coverage is indeed a good indicator. These are when the code coverage is really low. In those, the number means a greater part of the codebase is not being tested and therefore tests are not ensuring we are not introducing errors.

Additionally, creating good automated tests can reduce the amount of time spent by the QA team on performing regression tests. This very likely reduces the time they spend testing the same code over and over again, increasing the team's delivery velocity.