A discussion in the Software Testing & Quality Assurance group on LinkedIn concerned itself with the distinction of the terms quality assurance and quality control as they apply to software. Some points raised in that discussion seem worth mentioning.
To quote from Wikipedia:
Quality Assurance refers to administrative and procedural activities implemented in a quality system so that requirements and goals for a product, service or activity will be fulfilled. It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention. This can be contrasted with quality control, which is focused on process output.
Let’s examine that mouthful.
Put simply, quality control equates to software testing. This is something that spriteCloud does, and something that many other companies do by offering testers to their clients. Usually that means executing a test plan against a product or release candidate, but it can also involve exploratory testing.
Quality assurance traditionally refers to activities intended to insure that errors will not crop up in future, which involves root cause analysis – it may be that a bug was introduced by a developer working under time pressure, or that the specifications were misunderstood. If the specifications were misunderstood, that may be because they were unclear, or because they changed during development. Either way, root cause analysis tries to find the reason an error occurred, and it is a function of traditional QA to implement or at least suggest process changes to avoid the same mistakes.
As we are an external company working to fit into our clients’ processes, we cannot always fulfil this function on our own. But more often than not, project post-mortem reviews we try to hold with our clients highlight root causes, and we try to consult our clients on changes they can implement in their processes to avoid the same mistakes in the future.
This kind of traditional QA function tends to be expected, not necessarily of all external QA personnel, but at least of the development team as a whole – a term we’ll use loosely here to include everyone in the production chain. In an established organization, quite often this and similar traditional QA tasks are performed by a dedicated QA team. When we are hired as an external QA team, we try to fulfil this function as much as the relationship with our client demands.
It is perhaps regrettable that in the software world, the terms quality control and quality assurance are not entirely distinctly understood. In practice, it means is that some people with QA job titles are only able to fulfil QC roles.
On the other hand, this distinction may only serve to artificially create a two-class quality culture. After all, in order to build great products, all you need are people able to fulfil certain tasks well. As long as it is understood what can be expected of software QA, does it matter whether the terminology matches more traditional fields? What do you think?