The difference between quality assurance (QA) and testing is often misunderstood. In fact, the terms are frequently used interchangeably.
However, testing is actually just one part of QA. Quality assurance, on the other hand, covers a larger, more holistic part of the development process. Product flaws are not always a result of bad implementation, but they can often arise from bad design.
Using QA throughout the development process, along with peer reviews for all testing and quality assurance documentation, can ensure that products aren’t released with fundamental design flaws – design flaws that can quickly change the fortunes of even the biggest companies.
Quality Assurance can be divided into several different activities, only one of which is the traditional product testing for flaws and bugs. Other activities include defect prevention, inspections and peer reviews.
Defect prevention uses root cause analysis to discover why a defect occurred and attempts to ensure that the same type of defect doesn’t recur during product development. Such root cause analysis requires a system to log all classes of defects along with processes to identify the possible causes of the defects as well as actions to eliminate those causes.
Inspections can be applied to a variety of development activities including design inspections, code inspections and unit test inspections. An inspection needs to look at the product from an external point of view. For example, code inspections are performed without actually executing the code.
Linus Torvalds, the creator of the Linux kernel, once wrote about his dislike for debuggers without which you are forced to “look at the level above sources. At the meaning of things . . . you basically have to go the next step: understand what the program does. Not just that particular line.” His sentiments are equally true of inspections (code or otherwise) to the whole nature of quality assurance compared to just simple testing.
Peer reviews provide a formidable tool in the pursuit of quality. The result of each phase of the development process is reviewed by those qualified to understand the material (peers). Then the output from that review is fed back into the development process. Equally applicable to design, implementation, testing and deployment, the peer review process can spot flaws consistently. The old adage that two heads are better than one is applicable here.
Such quality assurance practices do not negate the need for detailed testing at every level, but rather they support the testing strategies to find flaws – and fix them. Such strategies should include black-box testing, white-box testing, system testing, stress and load testing and so on. Applying the processes of inspection and peer reviews to these traditional testing methods will also ensure that the testing phase itself is included in the overall quality assurance process.
For organizations that don’t practice these quality assurance activities – but are familiar with traditional testing methods – outsourcing quality assurance can be a cost-effective way of introducing these new skills. Also activities like peer reviews and code inspections are ideally suited to external agencies as working development environments or prototypes aren’t required.
The use of quality assurance practices coupled with traditional testing can ensure that products are shipped without crippling flaws but instead have quality built in.
