Making the Business Case for Application Testing

Photo by Christina @ wocintechchat.com on Unsplash

"We need to invest in testing" loses almost every budget conversation it's put into, because it asks for cost now against a benefit that's vague and in the future. The argument that actually works is narrower: not "testing is good," but "this specific bug class costs us this much, this specific kind of test would have caught it, and here's what that test costs to build and maintain."

This covers why the vague version of the pitch fails, the cost comparison that survives scrutiny from someone whose job is to say no to spending, which kind of test to propose first and why it's rarely the one engineers reach for, and the one thing not to promise, because the business will hold you to it.

Why the vague pitch fails#

"Untested code ships bugs" is true and unpersuasive, because it's a general claim about software and the person deciding the budget has heard it before from every engineer who ever wanted more time. What changes a no into a yes is a specific incident with a number attached: the checkout bug that shipped last quarter, how many orders it affected before anyone noticed, how long the fix and the customer-support cleanup took. That number is the actual cost of not testing that particular path. A testing budget pitched against a specific, recent, counted incident competes on the business's own terms. A pitch about testing in the abstract does not.

The comparison that holds up#

The honest cost comparison isn't "testing costs nothing and bugs cost everything." Testing has a real, ongoing cost: the time to write tests, the time to maintain them as the feature changes, and the CI minutes to run them on every push. The case for testing is that this cost is smaller and more predictable than the alternative, not that it's free.

The comparison that lands with a budget owner isn't "zero versus something," it's "a known, budgeted cost versus an unknown cost that tends to show up during an incident, at 2am, in front of a customer." Predictability is the thing finance departments already optimize for; frame the pitch in those terms and it stops sounding like an engineering preference.

Which test to propose first#

The instinct is to propose comprehensive coverage everywhere. The pitch that actually gets approved is narrower: tests for the path where a bug is both likely and expensive, which is usually not where engineers assume. Checkout, billing, and anything touching money or an irreversible action (sending an email to every customer, deleting an account) are expensive-when-wrong paths regardless of how often the code there changes. A low-traffic admin screen that breaks loudly and gets fixed in an hour is a cheap-when-wrong path even if it has zero tests. Propose coverage for the first category before the second, and say so explicitly, because a business owner who's been burned by over-broad "we need 100% coverage" asks will trust a scoped ask more than a blanket one.

// Worth writing first: the invariant that, if violated, costs real money
// and is easy to get wrong during a refactor six months from now.
public function test_cannot_apply_discount_code_twice_to_same_order(): void
{
    $order = Order::place($customerId, $lineItems);
    $order->applyDiscountCode('SAVE10');

    $this->expectException(DiscountAlreadyApplied::class);
    $order->applyDiscountCode('SAVE10');
}

What not to promise#

Don't promise that testing eliminates bugs. It reduces the rate and, more usefully, moves the ones that slip through earlier in the pipeline where they're cheaper to fix. A pitch that implicitly promises zero defects sets up the first post-launch bug as proof the investment failed, and that's the version of this conversation that kills a testing budget for the next two years. The claim that survives being wrong occasionally is "this catches the regressions that were costing us the most, most of the time," not "this means nothing ships broken again."