To borrow from another phrase, “defects happen.”
Even six sigma processes are not without defects.
By definition, a six sigma [manufacturing] process is one in which 99.99966% of the products manufactured are statistically expected to be free of defects.
That amounts to an average of 3.4 defects per million opportunities.
We are left to ask how much is reasonable to invest in those last 3.4 defects…
It is not the role of QA to prevent defects
Over the last couple weeks there has been a great conversation on LinkedIn about the role of QA in preventing defects from getting into production. Please take the time to check it out and join the conversation.
In the first response to the original question, Brian Will pointed out a distinction between the startup firm or the software company releasing to 1M+ end users… and then again to the medical device startup with respect to quality assurance.
Meanwhile, a colleague and friend of mine named Tom Gagne has a blog titled “Anything worth doing, is worth doing poorly” – a quote from a bank executive known for getting things done… quickly and (as far as I am aware) effectively.
So given that six sigma doesn’t eliminate defects, and given that distinctions for quality (viz defects) appear relative, the domain of quality assurance is not specifically about eliminating defects, either.
One consistency in all matters related to quality, however, is the domain of “trust production”.
Regardless what units you use to measure quality, as soon as you assess that quality is poor you get a little more skeptical about the product or service.
That’s when you take on added costs to check and double-check. That’s when you may look for alternatives, if you didn’t already.
In “A fourth rule for agile project managers,” I mentioned the unfortunate circumstance that software/IT customers sometimes suffer from “a deeply ingrained history of unmet expectations”.
In those cases, they may actually trust that your products will be awful.
So one factor generally missing from most conversations about quality is elapsed time.
It seems we typically look at QA with regard to defects for a given software product or release. We treat the domain as if those defects exist only at a point in time.
Meanwhile, defects always appear within a history of successes and failures that produce assessments of confidence in our ability to deliver – positively or negatively. Even if this is the first release, defects start the history on a bad note.
Given time as an additional dimension of quality assurance, customer service becomes a significant factor in public assessments of quality and value. Defects happen, but how we respond when they happen has a profound impact.
In addition, thinking on a longer time horizon than one release allows notions of “good enough” or “done enough” to start producing business value quickly even when some defects are known to exist or some features are not fully implemented.
Finally, a temporal consideration for quality promotes practices that can improve consistency, repeatability, reliability and competence in all aspects of software development… not just the “gauntlet” prior to production release.
What do you think about “trust production” as a form of quality assessment that takes shape over time?