“Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software-development techniques you use determine how many errors testing will find.”

? Steve McConnell, Code Complete

More Unit Testing isn't the answer, although it may catch some of the more egregious errors. I blame development managers that have adopted Agile and used that as an excuse to drop design/code/test reviews.

Anyone who remembers SEI (Software Engineering Institute) will remember that the incorporation of reviews in Level 3 is where you got real gains in productivity and quality. With Design Reviews and Code Reviews (and Test Reviews), you not only catch obvious bugs, but you often uncover misunderstandings that can lead to more deep-seated problems - ones that don't show up until you are in production.

Active reviews, where the developer actively presents their designs and code to one or more reviewers, foster good techniques throughout the organization as well as catching problems early in the development cycle. New developers may not realize that there are excellent existing algorithms or other techniques that are simpler and more robust than their design approaches. Plus, just the act of "presenting" the design/code approaches often results in the developer realizing they missed something, or had intended to handle some situation, but somehow forgot/overlooked it.

Agile doesn't forbid the use of reviews, but too many proponents seem to think that reviews aren't necessary because of the short "sprint" methodology. And thus, I get handed systems that "passed testing", but fail or perform inefficiently in the real world, where if any experienced developer had looked at the coding, they would have recommended simpler and better approaches.