Today I learned

Today we had a presentation and discussion about our quality assurance process. How we want to ensure that the work that we do is of good quality. During that we couldn’t quite grasp what quality really is. There some metrics involved, like test coverage, test plans or acceptance criteria. But these metrics don’t make quality measurable. You can have a 100% code coverage and still not have a batter product. Quality itself didn‘t emerge as property out of this discussion. It’s not a thing that you can easily measure, like this product has 7 out 10 quality.

Of course the might be obvious indicators that what you are doing is of bad quality. For instance availability of your application or number of bugs you get reported by users. You can of course optimise for these metrics by trying to get little bug reports from your users or by having a high availability. But these metrics in itself don’t make your quality measurable. Just because you have no bugs reported by your users might not mean your product is good.

It became also apparent that quality isn‘t a process. A process can support to ensure certain aspect of your work that you think is important and helps you to achieve quality, but it is not quality itself. Processes like continues integration, code review or requirements engineering are a component of achieving good quality but they are no indicators of quality itself. You can follow your requirements engineering process to the letter and still not capture what the product really needs to do.

Quality also isn’t a thing where you can just throw people or money at. You can just have a single team that takes care of quality. You often see this in the form of a Quality Assurance team that is task with “improving the quality”. They then often come up with processes or metrics that make quality measurable and the ultimately allow to optimise that metric. If this really contributes to a better product is at least questionable.

In the end we concluded that quality is more or less a mindset and not a property. Where everybody participating in building the product has to participate. No matter if leaders, product managements, developers, operations, everybody has to see achieving quality as goal in their work. And most importantly it doesn’t matter if you follow a rigorous process with lots of rules. Most of the time achieving quality is using common sense instead of following a checklist. At least in the domains that I work. Of course there domains like medical where rigorous is used to ensure safety of a product but this doesn’t mean that product is of good quality.