You branch for release.
You start testing.
You find a bunch of bugs.
You keep testing as people fix the bugs.
Now you have choices: you can verify the bugs, or you can continue to expand your test coverage.
Which do you do?
Arguments for increasing coverage:
- You found bugs in the first stuff you looked at; you have to assume there are major bugs in the stuff you haven't looked at. Looking earlier will help you find them earlier.
- Bugs tend to be found in clusters. Emphasizing verification only wears more roads in that clustered area - providing less new information.
Arguments for verifying bugs:
- Fixing bugs may cause bugs - you need to find the collateral damage. It helps to find it earlier while the code is still fresh in everyone's mind.
- Verifying bugs lets you finish out a cycle (in this case, the test -> find -> diagnose -> fix -> verify bug cycle), and that leaves fewer loose ends. It's satisfying for most people involved to complete something like that.
The real answer, of course, is that you don't do either exclusively. You spend some time on verification (and finding collateral damage), and some time expanding your coverage to areas of the product you haven't hit. However, in the need to balance both, consider where your risks are. If you have a high collateral damage occurrence, weigh toward bug verification. If you haven't hit much of the product yet, or if you have teams sitting idle, weigh toward increasing coverage. Take a look at your team, your product, and change your testing strategy accordingly.