You Can’t Test Quality Into the Code

… yet it is surprising how much we still rely on testing as our primary defence against defects.

To produce quality products consistently, the process must also have the objective of removing all defects before test entry. The objective of testing then becomes to verify and validate the product – not to fix its defects.

This is not just a theory or an idealistic view of what might be possible in the distant future – this is something that actually can happen.

At one point in my career I worked on a very large project at another software company.  There were almost 1000 people on the project, and it resulted in a product that has been widely recognized as being one of the most solid and reliable pieces of software in the industry. Yet the QA group within that was less than 1/10 of the total staffing. How could that be? Most projects we are familiar with typically have a QA group that is at least 1/2 the size of the programming group if not larger.

There were many contributing factors, but a key one was this: Every programmer was expected to produce essentially defect-free code, leaving only a few tasks to QA such as system test, load test, stress test, and any testing that required complex data, scenarios, or environments. As a programmer I remember very clearly having every one of my technical designs critically reviewed by my peers and all the resulting comments and corrections, the time well spent on unit test, the glee expressed by some of my programmer “friends” whenever they would find a defect in my code during a code review, and the mortification of receiving a defect report from QA once. While this might sound like a shame-based culture, it really didn’t feel that way at all. It would be better described as one of competitive excellence in which everyone felt a keen pride in their work and felt a strong desire to produce really good products.

I see no reason why we can’t make our culture more like that. And if pride in one’s work isn’t enough, one additional thing we have going for us is that our software really matters – most of it is used in hospitals by medical people who are working on matters of human health, sometimes life or death – so what better motivation could there be to produce quality software than that?

So you can’t put the quality in by testing – it has to go in from the beginning, starting with good designs and code that programmers are confident in and proud of as theirs.

About John

John Peterson has been creating and managing the creation of software for his entire professional life. During that time, he's been through many projects large and small, worked with a wide variety of people on a wide variety of technologies, made a lot of mistakes, and learned a lot in the process. The intention of this blog is to pass along the wisdom he has accumulated in the creation of software to those who may be earlier in their path of experience.
This entry was posted in Execution, Quality. Bookmark the permalink.

Leave a Reply