Suppose you’re working on a project and the time/money budget does not allow 100% coverage of all code/paths.
It then follows that some critical subset of your code needs to be tested. Clearly a ‘gut-check’ approach can be used to test the system, where intuition and manual analysis can produce some sort of test coverage that will be ‘ok’.
However, I’m presuming that there are best practices/approaches/processes that identify critical elements up to some threshold and let you focus your test elements on those blocks.
For example, one popular process for identifying failures in manufacturing is Failure Mode and Effects Analysis. I’m looking for a process(es) to identify critical testing blocks in software.
100% code coverage is not a desirable goal. See this blog for some reasons.
My best practice is to derive test cases from use cases. Create concrete traceability (I use a UML tool but a spreadsheet will do as well) between the use cases your system is supposed to implement and test cases that proves that it works.
Explicitly identify the most critical use cases. Now look at the test cases they trace to. Do you have many test cases for the critical use cases? Do they cover all aspects of the use case? Do they cover negative and exception cases?
I have found that to be the best formula (and best use of the team’s time) for ensuring good coverage.
EDIT:
Simple, contrived example of why 100% code coverage does not guarantee you test 100% of cases. Say CriticalProcess() is supposed to call AppendFile() to append text but instead calls WriteFile() to overwrite text.