Almost a decade ago, Albert Savoia walked on stage at the Google Test Automation Conference (GTAC) dressed as the Grim Reaper. With The Doors song ‘This is the End’ playing in the background, Savoia famously declared testing dead. Dead were the days of developers delivering crappy code, then waiting for QA to test it and decide when it was finally fit for release. Instead, he suggested, we should deliver immediately and test in production. See what issues arise, then roll back the deployment if something severe occurs.

Are we there yet? Is the idea of testing a release before sending it out into the wild really dead? To answer that question, let’s consider another example that involves death and the wild: the annual wildebeest migration in Africa.

Every year, over a million wildebeests migrate between Tanzania and Kenya. Along the way, they must cross the crocodile-infested Mara river. As you can imagine, this is a rather high-risk activity. Risk is the probability of a damaging event occurring, multiplied by the potential damage that could result from that event. In this case, the probability of facing one of the many huge crocodiles who are lurking in the river, anticipating the best feast of the entire year, is relatively high. The potential damage—death—is extremely high.

The riskiness of this situation would dramatically decrease if the crocodiles in the river were cute little 7- to 10-inch baby crocs instead of monstrous 17- to 23-foot adults. Even if the probability of encountering a crocodile remains the same, the potential damage diminishes tremendously. At worst, the baby crocs might nip at the wildebeests’ feet or make their path across the river just a little bit bumpy.

What does this have to do with the death of software testing? Quite a lot, actually. If you want to rapidly release untested software into production, you need to be aware of what level of risk this involves, then consider whether that level of risk is acceptable to your business.  As you can see from the large crocs versus the baby ones, all risks are not created equal.

If you’re a social media platform updating the Recommended Friends algorithm, there’s not much risk involved in moving fast and breaking things. Even if there’s a high probability of users encountering issues, the impact to the business is extremely low. It’s probably equal to, or even less than, little baby crocodiles nipping at the wildebeests’ feet.

On the other hand, now imagine that you’re responsible for the back-end systems that control business-critical operations such as financial transactions or energy delivery. You won’t have nearly as many users as the social media platform, but any failure that does occur would be extremely critical and damaging.

Since the risk with the theoretical social media platform is low, they can get away with crossing the river without first “testing the waters,” so to speak.  If they’re working on more critical functionality—for example, something that impacts their advertising revenue—they might want to be a little more cautious and creative. In that case, they might decide to perform an incremental user deployment. Essentially, this is like sending a small, low-priority group across the river first, then sending increasingly more (and more important) users over the river as long as no major “crocs” are surfacing.

With an application that the business depends on, you simply can’t afford to send even a small group of users over untested waters. The risks—like the adult crocs—are huge and potentially devastating.

If you can truly afford to send users across untested waters, then maybe you can declare testing dead. However, if you’re working on essential enterprise software and you try to survive by “testing in production” alone, it’s your business that might end up dead—killed by those crocs.