Quality must be built into our products; it can never be tested in after the fact. Although QA has an important role in assuring the quality of our products, their work is entirely indirect. Their role is to influence others in the organization. It is those other people who will build quality into our products. (Or not.)
The primary responsibility for quality lies with management, beginning with the highest executive ranks, and continuing all the way to first line supervisors. It is management who establish priorities, set the tone, define the culture, and show the employees what is "important". All of the members of the organization will follow management's lead. Even if they wish that management would change their priorities, people will still align themselves with management's actions.
So, how should management act in order to foster an environment in which high-quality software is built? The first thing they must do is to ask about quality. Don't ask about schedule without also asking about quality. Don't be concerned about budget variance without also asking about quality variance. Don't set cost objectives without also setting quality objectives.
Of course we will not be able to ask about our organization's quality performance until we understand our historical quality performance and establish targets for our projects. And we will be unable to ask pertinent questions about quality until we achieve a working understanding of the metrics that will provide the perspectives we need.
In short, if we are to lead our organizations toward achieving better quality results, we must educate ourselves about quality. Just as we have established a good understanding of how to manage budgets and schedules, we need to learn how to manage quality. We need to familiarize ourselves with the costs and the benefits of each quality-related activity our projects may employ so we can invest in the activities that will pay dividends, improving our quality performance without negative budget and schedule implications.
Management's role is to educate ourselves so we can make wise investments in quality, and ask our staff questions that will guide them to value good quality performance.
Second only to management is the programming staff's responsibility for quality. The quality of a system is just like any other attribute or feature; it will not be a part of the system unless those who build the system build it in. Quality cannot be tested into a system, just as knowledge cannot be tested into a student. The quality of a system is the net result of the care with which all of the engineering activities have been undertaken.
So, how should the programmers act in order to improve the quality of the systems they build? Their first step in improving their performance (along any dimension, be it quality, productivity, or technical skill) is to understand their current performance. Each engineer should measure the quality of the programs he builds, and gain a functional understanding of his capacity to produce consistently high-quality products.
Just as every pitcher knows his Earned Run Average, every runner knows her average and best times for each race, and every running back knows his average yards per carry, each programmer should know her average defect density, productivity, and defect injection rates for design and coding activities. Armed with these statistics, the programmer (like the athlete) has a basis for setting improvement goals and altering behavior in order to make progress toward them.
And just as teams employ coaches to guide athletes in improving their performance, so also programmers need the guidance of knowledgeable individuals to help them to set and achieve quality-related goals. A coach can help programmers to collect appropriate statistics, to interpret those data to understand what they mean, and to identify opportunities to excel. Also, a coach can guide programmers in setting professional goals for themselves and adapting their work habits in order to achieve those goals.
If QA cannot be responsible for adding quality to the product, then what is their role? QA's role is to be management's eyes and ears to understand how well software is being built and to know when corrective actions are needed.
By measuring and monitoring the software development process, QA helps to determine if the organization's standards and processes are being followed, and if they are effective in helping the engineering staff to do excellent work. When standards are being ignored or circumvented, QA identifies the reasons for the problem, and helps management to determine the steps that must be taken to bring the development activities in line with expectations.
By testing and auditing the products of software development, QA establishes the quality levels that are being achieved so management can determine if the organizational processes as suited to the needs of the projects. When defect levels are higher than expected, QA can help to identify the reasons for this, and the actions that will correct the problem.
The road to excellent quality is a long one, but one that you can embark on today. Getting Management's, Developers, and QA's roles into proper alignment will lay the foundation for the cultural shifts that are necessary to achieve high quality.
When Management begins to regularly and consistently raise quality performance as an important issue, the others in the organization will begin to pay appropriate attention to it. When the programmers key off of management's new focus, they will begin to build quality into their products, lifting the entire organization's performance. Finally, as QA expands its role beyond merely testing and finding defects, they can help management to put the entire organization onto the road of continuous quality improvement.