In one of my favorite conversations with Devlin, we explored a topic that every software team grapples with: why do we write tests, and what’s the real business case for them?
This wasn’t a conversation about frameworks or acronyms. It was about cost, value, and alignment; how testing impacts revenue, customer trust, and the total cost of ownership.
Back in 2020, I wrote a post titled Why Are You Writing Tests?. In it, I admitted that early in my career, I used to say, “I write tests to make sure my code works.” But that answer never satisfied business stakeholders. From their perspective, isn’t that what developers are supposed to do anyway: deliver code that works?
Over time, I reframed my understanding: I don’t just write tests. I write specifications. These are living documents, written in executable form, that capture the why behind the feature, not just the how. When expressed in the correct language, these specs can be read and validated by both technical and non-technical stakeholders. That changes the conversation entirely.
The Translation Gap
Devlin and I talked about the gap between what business stakeholders describe and what developers deliver. Requirements often say what to build and sometimes even how, but rarely why. That gap creates costly round trips: developers build something, business users reject it, and the team has to rework it.
Testing early, in the form of collaborative specifications, closes that gap. It ensures that when we add two numbers together, we’re not just building a calculator: we’re handling dollars, pesos, and pounds correctly. It ensures that a “cancel button” cancels an order, not just closes a screen. That’s the real value of testing.
Cost Now or Later
Bugs are cheapest to fix on the developer’s machine. The further they get—from test to staging to production—the more expensive they become. And those costs aren’t just technical: they include customer support time, brand damage, lost trust, and lost opportunities.
Testing is an insurance policy, but not one-size-fits-all. Crash-testing every car model (not every car built) is expensive, but necessary. Likewise, not every feature needs exhaustive coverage. Instead of obsessing over code coverage metrics, I prefer feature coverage; prioritizing tests for the features most critical to the business.
A Cultural Shift
Testing isn’t just about tools or coverage; it’s about communication and collaboration. Developers don’t need to “dumb down” their technical language, and business users don’t need to learn Java or SQL. What both sides need is a shared language, where specifications are written in terms everyone understands.
And if your organization doesn’t yet value testing, don’t wait for permission. Start by writing specs in business language, review them with stakeholders, and let the results speak for themselves. Like a surgeon washing their hands before surgery, it should be seen as a standard of care, not an optional step.
Moving Forward
The business case for testing is simple: it reduces rework, lowers the total cost of ownership, and increases trust between teams. But the deeper case is this: it aligns developers and business stakeholders around a shared understanding of purpose.
The hardest part of solving a problem is defining it well. Good tests, written as specifications, are how we get there.
Watch our complete conversation on this topic here:
Leave a Reply