Minimum Viable Quality

We've all heard of the concept of the Minimum Viable Product. It's a core component of The Lean Startup methodology and the first element of the build-measure-learn feedback loop. If you haven't had a chance to read it, I really recommend picking up a copy of The Lean Startup. (and yes, these concepts apply to everyone, no matter the size of your company)

I came across the concept of Minimum Viable Quality a few months ago, when I was reading through my feed of quality and testing blogs, and it piqued my interest.

As many of us are trying to rapidly ship our software and get it into the hands of our customers as soon as possible, traditional approaches to testing are no longer providing the value that they used to. We're accustomed to periods of regression testing and product hardening phases, but these approaches slow down our delivery.

Here's a great diagram that gives a brief overview of MVQ.

Ken Johnston’s “Minimum Viable Quality (MVQ)” testing model

Using this approach to testing should get our products into production sooner, for real users to provide us with faster feedback. However, you'll need to find the balance between minimum viable quality and poor quality; if no one uses our product, then we are no longer learning what we should be developing next.

We need to be comfortable with shipping buggier software as fast as possible because the speed at which we release software is a key competitive advantage.

I'll be sharing this concept in late July with a group of Quality Assurance professionals from my company and I plan on reporting back with the questions and comments that come out of that session.