Continuous Testing for DevOps Teams
Minimum Viable Quality - Why startups should start thinking about it
Qapitol QA > Blog > Quality > Minimum Viable Quality – Why startups should start thinking about it
qapitol qa testing blog

Minimum Viable Quality – Why startups should start thinking about it

  • Quality, Startups
  • No Comments
  • Sreedhar

Scenario 1 – You are given a car to test-drive and told, it is a basic shell that has been quickly cobbled together, with an engine that we think will move the car forward but has not been tested; has brakes but not sure if the car will stop if traveling beyond a certain speed;

Scenario 2 – You go to a newly built multiplex and experience problems with the car parking system, ticket vending machine, the audio system inside the theater and the pop-corn machine. You would obviously rate the overall experience negative and share your experience with friends and family and if you are a social media enthusiast like most of us today, you will even share your experience on Facebook, Twitter, WhatsApp and other channels. Most importantly you will have a very strong bad memory of the day etched in your mind and in future, any reference to the multiplex will first be correlated to the first experience.

These 2 scenarios reflect the status of Minimum Viable Product (MVP) in today’s startup world. For various reasons, the startups are of a mind-set and possibly taught by their respective mentors that MVP means a structure which is just bones, loosely hinged and delivered as a product delivered to potential customers to gather feedback about the founders’ idea. And in majority of the cases, MVP has left a bad taste in the mouth of potential customers. This has resulted in customers not wanting to come back to the product, even when it gets launched as a full product.

Ofcourse time is of the essence when you are a startup and crunched for resource, most importantly time and money. However, what the founders tend to ignore is that it is the same resource wasted, when you try to cobble something together and release the bare-bone structure into market, without checking the product for Minimum Viable Quality.

It is well-known and widely accepted that the product building team, including founders, designers and architects, tend to develop blind spots, since they live with the product day-in and day-out. With the current trend of ‘Delivery to be done by Yesterday’, developers have little or no band-width to test the product for Minimum Viable Quality thereby resulting in a poor quality MVP being launched. Ofcourse MVP is to indicate if the product should be built to begin with. However, in most of the cases, there is too much focus on Minimal with little focus on Viable.

The questions that I frequently get asked are What is Minimum Viable Quality? How much is good? How best to achieve Minimum Viable Quality with minimum resource (time and money) spent?

¬ MVQ is more than just testing the software. It is ensuring that
⎫ Customer understands what problem you are trying to address
⎫ If your product is a mobile application or packaged application, customer is able to install the application successfully on the device
⎫ Customer is able to navigate, without any issues, the minimal features provided.
¬ Unfortunately there is no shortcut to success. Invest in either a QA analyst or outsource to a QA vendor. Either ways, someone who is aware of the product but works independent of the product design and development team so as to not develop blind spots. This will ensure you don’t have to have rework on an otherwise bad quality MVP, resulting in saving time and money.

Make MVQ part of your plan at the IDEA stage. It adds more value than you can imagine.

Author: Sreedhar