No one wants to release bug-ridden products. However, opinions waver when it comes to the best way to achieve excellence. Check out what some TechRepublic members are saying about quality assurance and where it should stand in the enterprise.
Any organization that intends to survive in the brutal IT marketplace is expected to provide a quality product or service to customers. However, as so many IT professionals know, enterprise-wide measures to guarantee quality can be difficult to develop and expensive to maintain.
In his recent article “The rebirth of quality assurance,” TechRepublic columnist Tim Landgrave advocated the efficacy of a dedicated quality assurance (QA) department to evaluate software development products. However, according to comments from a discussion in response to the article, some TechRepublic members believe that QA departments are the wrong approach to boost product excellence. This article explores some member thoughts on QA departments and where they fit in organizations undertaking development projects.
The cart before the horse
In many cases in which there’s a department dedicated to a certain job function, there will be some sense of disparity between one department and another—no matter how collaborative and efficient the organization as a whole may be. According to member Wayne Mack, dedicating a QA department to improve the fruits of developers’ labor sends the wrong message to those employees on the development end.
“Quality must be placed in the hands of the developers, not in a separate organization,” wrote Mack. “We cannot have quality if we continue to believe that developers are incapable of producing quality and need an oversight group to ensure quality.”
Mack believes that developers can become over-reliant on the QA department’s regimens of tests and inspections. The actual processes and methods of developing the product suffer because expectations of and responsibility for quality are absent from the developers themselves.
The problem with integration
Although Dennis Dickens agrees that developers should be more responsible for building quality into the end product, the very nature of development work necessitates “a separate set of eyes not directly involved with the project to find additional problems.” After many hours of crunching out code, quality-oriented methods and tools are unlikely to catch all of the small potential problems.
“That is where a QA group could come into play. They would ask the obvious questions you’ve already answered and ask additional questions that you didn’t consider.”
Like many IT professionals, Angelo Serra believes in bug-free software. However, despite developers’ most ambitious efforts to deliver sound code, Angelo points out that development projects are often driven by “distributed-system and multi-person teams.” With so many hands involved, errors are imminent. That’s reason enough, according to Angelo, “to support consistent testing…by a separate function [QA].”
QA vs. QC
When David Wearing worked in an environment heavily focused on quality assurance, he found himself mired in a discouraging bureaucracy. People became so involved in trying to define what quality assurance was and what it meant for the company that they lost sight of the value that it was supposed to add to the organization. One of the reasons Wearing left was because of the mess that grew around the emphasis on quality.
Although too much debate can be counterproductive, several members do believe that it is important to distinguish between quality assurance and quality control. Although definitions will undoubtedly differ between companies, David L'Heureux, a QA/QC consultant for the past eight years, believes that definitions from the Quality Assurance Institute are useful for pondering QA’s role in development projects.
In short, L'Heureux cites quality control (QC) as the actual testing processes that determine whether or not a product is ready to move on to the “next phase of its lifecycle.” QA, on the other hand, is an exploration of the processes involved with production and it focuses on how those processes can be improved.
If one is willing to accept these definitions, a kind of middle ground seems attainable. QA efforts place some of the burden on developers to create production systems that deliver quality results; QC testing covers the seemingly omnipresent margins of error in so many projects.
Should QA stand alone?
Will QA better serve companies as a distinct department or should it be integrated into the development process? Click here to join the discussion and share your thoughts.