"What does your quality assurance group do?" I have asked this question of many executives. Too often they answer, "Quality assurance is responsible for testing our software to ensure it is ready for release." I push, hoping for more, by asking, "Anything else?" Usually, though, the response is little more than, "Well, they manage the defect tracking system. What else would they do?" What more, indeed!
Just as there is much more to configuration management than merely doing good version control, quality assurance goes far beyond mere testing. Indeed, I have seen companies where the quality assurance (QA) group doesn't do testing at all; that is the responsibility of the testing or quality control group. Their QA groups are responsible for all of the other activities that are necessary to really assure quality.
Quality Control versus Quality Assurance
Testing is a quality control (QC) function. What is quality control? QC includes any activity that examines products to determine if they meet their specifications. As this definition applies to software, the specification may be either written specs, or needs as defined by the customer or end users. Not only is testing a QC activity, but so are walkthroughs, reviews, or inspections of work products like requirements, designs, code and documents.
If none of these activities are a QA activity, what do we do in our organization that is QA? Unfortunately, most of us are doing little or no quality assurance. QA includes any activity that focuses on ensuring that the needed levels of quality are achieved. In essence, if QC is about detecting defects, the QA is about avoiding them! QA activities include identifying problems so steps can be taken in the future to avoid those same problems. It includes engineering the processes that are used by the team (analysts, developers, testers, writers) so that high quality products can be built efficiently. This includes ensuring that each team member is performing his or her job consistently and producing consistently good results.
Identifying Improvement Opportunities
Every organization has many opportunities to improve the methods and processes they use. The problem lies with identifying what problems need to be fixed and where it would be most useful to invest in improvement. One of the main functions of quality assurance is to use the organization's own data to identify these opportunities. Your organization maintains a treasure trove of data, just waiting to be mined for valuable information: defect data, development effort data, cost data, and schedule data are can provide useful insights.
The QA analyst searches for patterns of inefficiencies, defects, or other problems. For example, if a certain kind of design flaw comes up consistently during system test, this could indicate the need to improve something earlier in the development process. What needs to be done must be determined by looking at the data from those earlier steps. Maybe a new design methodology would help. Perhaps the designers need to be trained in using the methodology or tools they already have. Maybe the design reviews can be improved or there are no design reviews being done at all (indicating an opportunity to prevent many kinds of design flaws during test). By identifying the high-value problem areas, the QA Analyst helps to ensure that the organization can produce better quality more efficiently on future projects.
Engineering Effective Processes
Even the most brilliant engineers and greatest tools can be made ineffective by poor or inconsistent processes. A big focus of quality assurance is on the processes that are used by those who produce the project's products, those who verify the correctness of those products, and those who manage the work. Writing a process is a relatively easy task. You simply identify all of the things that must be done, determine where the interdependencies are, and reduce this information into the patterns that each person needs to follow. If writing a process is easy, writing one that works well is not. Indeed, any initial process description or procedure must be seen as