When I first arrived in the US, I had a charming encounter that perfectly illustrates one of the most critical aspects of any creation: testing. My roommate, Alexandre, a fantastic French cook, and I hosted a dinner for some friends, including Fuyuko, a Japanese girl new to Mexican food. Alexandre whipped up a delicious meal. Not wanting to be left out, and despite my lack of culinary skills, I offered to make something simple for Fuyuko: guacamole.

I followed a recipe meticulously, proud to present her with a small bowl of my creation. Days later, I ran into her on campus and asked about the dip. She started teasing me, calling it a “dip of glass.” Glass? I was baffled, picturing shards in my guacamole. Then she pointed to the lawn nearby. “Ahh, grass!” We burst out laughing, but my curiosity—and embarrassment—got the better of me. Back home, I tried my concoction. Sure enough, it tasted exactly like grass.

Had I tested “my creation” before serving it, I would’ve avoided that hilarious confusion and my red face. From that day on, I stuck to being a helper in the kitchen, never again offering to cook for anyone.

From Kitchen to Code: The Universal Need for Testing

My guacamole mishap isn’t just a funny story; it’s a perfect metaphor for the need for testing in any field. Chefs taste-test their food, not just at the end but throughout the cooking process. They even get independent opinions from peers. It doesn’t matter if it’s a new recipe or their signature dish they’ve made a thousand times; they always taste.

This crucial step isn’t unique to the kitchen. Think about cars, home appliances, or mobile phones. Every one of these devices undergoes rigorous testing before it hits the market, especially new models. Car manufacturers, with all their vast experience, meticulously test new designs. Electronic giants follow the same routine.

So, why should software production be any different? It shouldn’t be!

Software Development: An Art, a Science, and a Necessity for Testing

Software development has its unique blend of art and science. It’s an art, much like cuisine, requiring creativity and intuition. But it’s also a science, governed by formal principles, technology, and standards. However, no matter how knowledgeable or experienced a software development team is, they must test their system before it’s published or released to users.

This is where Software Quality Assurance (SQA) comes in. SQA encompasses two broad activities: verification (static testing) and validation (dynamic testing). Software engineering textbooks dedicate significant sections to SQA, detailing testing categories, techniques, and strategies. Roger Pressman’s “Software Engineering: A Practitioner’s Approach,” for instance, devotes entire chapters to quality management and even introduces testing concepts early in its modeling sections. This highlights just how integral testing is to the entire software development lifecycle.

For our discussion, let’s use Pressman’s definition of quality software: “An effective software process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it.” So far, we’ve established the need for testing, SQA, validation, and verification. But let’s get to the real question that matters to a CFO: what about the cost?

The Alarming Cost of Late Software Errors: A Financial Perspective

Finding and fixing errors is a natural part of software development. But the cost of those fixes dramatically escalates the later an error is discovered. Imagine a hypothetical software project lasting 100 weeks, with different percentages of effort for each stage: 20% for requirements, 25% for design, 20% for coding, 20% for testing, and 15% for maintenance.

Let’s assume one error is found and fixed each week. Based on Pressman’s 2009 figures (which would be significantly higher in today’s dollars due to inflation and increased complexity!), here’s a financial breakdown. To make this comparable to a capital investment, we introduce discount rates, accounting for the increasing risk (or internal rate of return – IRR) as a project progresses. Higher risk in later stages means that future costs, if unaddressed, are more impactful on your bottom line today.

The Staggering Financial Truth

Look at that last column: Total Discounted Cost. It clearly shows how quickly the cost of finding and fixing the same number of errors spirals out of control as the project progresses. An error caught in the maintenance phase (weeks 86-100) costs nearly 80 times more than an error caught during requirements gathering (weeks 1-20)!

And remember, these are 2009 figures. If we adjust for inflation and current developer salaries, these numbers would be exponentially higher today. Imagine if 30 errors were found during the maintenance stage instead of 15. Using the same formula, the cost would jump from $198,070 to over $370,000 for just that stage!

This isn’t just about avoiding embarrassment like my guacamole. It’s about protecting your organization’s budget and preventing massive financial drains.

A Message to the CFO

So, Ms./Mr. CFO: when your IT developers request funding for training in SQA techniques to catch errors early, or for hiring independent validators/verifiers, or for investing in software tools that automate and assist with these crucial tasks… please don’t see it as an expense.

Instead, compare the relatively modest investment they’re asking for against the potential Net Present Value (NPV) indicated by these error-fixing figures. I’m confident the numbers will overwhelmingly favor proactive testing, ensuring quality from the start, and ultimately saving your organization enormous sums down the line. It’s not just “playing with toys”; it’s a strategic investment in financial health.

In future posts, we’ll dive deeper, moving from software testing to the broader landscape of software development, IT support, and how it all aligns with business strategy. Stay tuned!

Note: This article was proofread and improved with assistance of Google’s Gemini.