By Rajiv Jain (CEO, ThinkSys)

Us veterans of the software product development game may be forgiven a bit of confusion these days. From the old days of the waterfall model of development, we are now faced with choosing between Agile development methodologies, DevOps and Continuous Delivery or perhaps rushing to churn out a Minimum Viable Product. Of these, the last, the MVP approach, is particularly favoured by startups or enterprises who seek to emulate the nimbleness of the startup. In a nutshell, the MVP is a kind of early Alpha of the product that is done fast and released early with a view to gathering customer feedback and either gain early market traction or fail fast enough to allow recovery. Steve Blank explains it well, “You’re selling the vision and delivering the minimum feature set to visionaries, not everyone.” The aim is to release, iterate and release again in short cycles. I could not find any reliable stats but anecdotal evidence would suggest that approach is rapidly gaining ground in product development – frankly, I’m not surprised considering how it gives maximum bang for the effort and money invested.

Among the MVP approaches, there are those that seem to focus on the “minimum” and are thus concerned only with seeking market validation of an idea through landing pages or crowdfunding campaigns. Ignoring those let’s focus our attention on those that focus on the “viable” and release actual products into the market. These products are generally single-feature or window-dressed versions or limited-feature versions of the vision. As such there is software design, architecture and development effort involved and of course where there is development testing has to follow. An interesting question to ponder is does test automation have a role to play in this kind of development?

But before that, one, only slightly, philosophical question is about the MVP itself. In many ways, the MVP itself is a kind of trial balloon, a test of an idea. The limited objective of the MVP is to seek customer validation and only if it passes that initial test is it on to the next stage. This suggests some strong factors in favour of test automation and a couple against it too.

While early customers do expect some rough edges to the MVP they are unlikely to forget or forgive poor quality and such early impressions could kill the product before it really lives. This means testing and QA cannot be given the short shrift even in the MVP. This then brings into focus the speed aspect. The product has to be released quickly, to start with as well in succeeding iterations as customer feedback piles up. Speed has always been one of the chief reasons to pitch for Test Automation. A natural fit it would seem!

Well, not so fast. There are a couple of other important factors that may make you change your mind. For one, the MVP approach does not lend itself well to long-term planning. This approach, by definition, does not provide any great visibility into the final shape the product is likely to take or even into upcoming versions. That’s not great news for those looking to build an effective test automation strategy given the lag time between defining what should be automated and deploying a well put-together automation suite. In the time, it takes you to develop an automation suite the test cases you are automating for may no longer exist! The other issue is applicability The shape of the product changes quickly from version to version so it would seem that many of the test conditions may not occur more than once. Clearly there’s not much value to automating test cases that will be used only a handful of times. So the prospects of test automation in the MVP scenario don’t appear that bright.

That being said though I see one possible connection, and it could be a key one. If you look at the MVP approach as a series of empirical experiments intended to define the final shape of the product, then this can become a wonderful early input into the automation strategy. In this approach, the product plans and, in turn, the test automation strategy can be much more “frozen” since the likely changes and iterations can be identified and accounted for very early in the process. This allows the test automation team more elbow room – they can plan better, design better and presumably execute better on those plans. This could be a big boost to the automation efforts.

So, my own feeling is that the process of building an MVP is perhaps too scrappy to allow for decent degrees of automation but that being said the end product that the approach itself seeks to build could benefit tremendously from a better-planned test automation approach. Let me turn to the leading light of the Lean Startup and MVP movement, Eric Ries for support. He said, “All innovation begins with vision. It’s what happens next that is critical.” Fair enough!