No kidding. This has been known for a long time but it&#x27;s good to see empirical evidence. The empirical evidence of 70&#x27;s-90&#x27;s showed the best ways to reduce defects were the following:<p>1. Unambiguous specifications of what the system will do.<p>2. Implementation in safe languages or subsets with plenty of interface checks.<p>3. <i>Human review</i> of design, implementation, and configuration looking for errors. Best results were here.<p>4. Usage-based testing to eliminate most errors user will experience in practice.<p>5. Thorough functional and unit testing.<p>(Later on...)<p>6. Fuzz testing.<p>7. Static analysis.<p>Practices 1-4 were used in Cleanroom, some major commercial projects, and high assurance security work. Every time, they produced results in preventing serious defects from entering the system that often might have slipped by testing. So, those are where the majority of our verification work should go in. Supporting evidence is from those that do a subset of that from OpenBSD team to Microsoft&#x27;s SDL along with substantial defect reduction that followed.<p>Note: 6 and 7 showed their value later on. No 7 should definitely be done where possible with 6 done to a degree. I haven&#x27;t researched 6 enough to give advice on most efficient approach, though.<p>So, internal testing and coverage are the weakest forms of verification. They have many benefits for sure but people put way too much effort and expectations into them where it pays off more elsewhere. Do enough testing for its key benefits then just cut it off from there. And don&#x27;t even do most of that until you&#x27;ve done code reviews, etc which pay off more.