Over the past twelve years, I have had the opportunity to lead the Engineering team in over a half-dozen companies, and have observed an incredible variance in how each of the engineers answered this question: “Who owns quality?”
For only one of the companies that I joined, has the answer met my own.
In my experience, answering this question properly – and building corresponding software engineering processes – is critical. How an Engineering team addresses the ownership of quality has fundamental implications on how it operates. It impacts just about everything!
- The daily tasks of each developer
- The daily tasks of each QA engineer
- The selection of software development tools and artifacts
- The sequencing of tasks in software releases
- The ability of the team to deliver quality product on time
The vast majority of answers fall into two bins: it is either “Everybody” or “QA”.
While it is hard to argue against the philosophy that everyone owns quality, this is an empty, and non-actionable, answer. When “everybody” is responsible, no one takes responsibility.
QA certainly has a big role to play in ensuring that we deliver high quality products. However, there is a fundamental reason why QA does not own Quality: they have little control over it: QA does not write the code, developers do. Asking QA to own quality is akin to asking the proverbial blind man to define the elephant! Asking QA to own quality implies a process where Quality is added after the fact, once the code has been written. Let us remember what QA stands for: Quality Assurance, not Quality Addition, or Quality Creation.
We all know that quality has to be built in, not added on.
To me, the right answer is: Developers Own Quality.
… to be continued