Testing as Insurance

Narrated

Last week, you added a new feature to the trip planner. Let’s say you built trip sharing, the ability for a user to share their itinerary with a friend via a link. You tested it. It worked. You pushed it live. You moved on.

This week, you’re working on something else entirely. Maybe you’re improving how photos display in the itinerary. You change how the trip data is structured so that photos attach nicely to each day. You test the photo feature. Looks great. You push it.

Three days later, a user emails you. “I tried to share my trip with my friend and the link just shows a blank page.” You check. They’re right. Sharing is completely broken. It’s been broken for three days.

What happened? When you changed the trip data structure for the photo feature, you accidentally broke the format that the sharing feature depends on. The sharing code expects the trip to look one way, and now it looks a different way. You never noticed because you only tested photos. You didn’t re-test sharing. Why would you? You weren’t working on sharing.

This is the most common way production applications break. It’s not that you wrote bad code. It’s that you fixed one thing and accidentally broke a different thing that you weren’t thinking about. Developers call this a regression. Something that used to work, regresses, stops working, because of a change somewhere else.

Now multiply this by every feature in your app. Authentication. Trip creation. Photo uploads. Payments. GDPR export. Every time you touch anything, any of these could silently break. And you won’t know until a user complains, or worse, until a user leaves.

The answer is not to test harder. The answer is to stop testing manually. Let a robot do it.