But this isn't quality assurance really. An emphasis on uncovering defects is more like quality control.
In true QA, the quality is built-in and the entire team is focused on quality at every phase of a project.
A recent post in the On Quality blog revived my concern about the almost universal lack of true quality assurance. I often wonder if quality would increase with a focus on the distinction between Quality Control and Quality Assurance.
On Quality's post gets strait to the point:
Does software quality come from testing?…No.
The problem is that QA's concern with what's seen doesn't address the unseen. And that, like an iceberg, is the larger part:
Testing can only address an application’s “external quality.” Testers can effectively address only visible symptoms such as correctness, efficiency or maintenance costs. What lies beneath the surface, however, the internal quality, directly impacts the external quality and can lead to even greater issues. These characteristics – program structure, complexity, coding practices, coupling, testability, reusability, maintainability, readability and flexibility – are the invisible root of the software quality iceberg and can do far more damage to a company’s reputation and IT maintenance budget than the visible issues.
The traditional approach, where quality is left to the developers, is problematic for a couple of reasons:
- ...time, business and cost pressures have all pushed developers to make sub-optimal choices that impact the quality and future performance of critical applications.
- ...there is just too much that needs to be reviewed for any individual developer – or even group of developers – to review efficiently and find the issues that could lead to application software malfunction.
The post recommends using automated tools to accomplish successful internal quality reviews. But before that happens, I'd advocate for a development process that spends more time on ensuring quality is built-in rather than ensuring that bugs are taken out.