Let’s Call Software Testing By Its Real Name

The Elephant in the Room

Can we have have an honest discussion about software testing? For many years now, we’ve danced around the real reason we dedicate substantial time and resources to testing software before releasing. It’s time to call a spade a spade – what we refer to as “testing” is actually “status determination”.

Status Determination: Reporting on the Current State

Testing, or status determination as I’ll contentiosly refer to it going forward, serves one key purpose: to report on the current status of the software under development. With each test execution, we’re essentially asking “Where are we at? What’s working as intended and what still needs to be fixed or improved?”

A Reflection of Our Development Approach

The need for rigorous status determination is a reflection of the current state of software development practices. If processes were truly stable and predictable, we would already know the status of the product without having to examine it through testing. But the truth is, our development approaches have instability and unpredictability baked in from the start.

Embracing Status Determination

Instead of deluding ourselves, we might choose to resign ourselves to the humiliating reality that status determination is a crutch upon which our development efforts desperately rely. It is a begrudging acknowledgment that teams simply cannot contend with the inherent complexities involved in crafting modern software systems through process and skill alone.

We lack the capability – the fundamental engineering wisdom – to make any credible predictions about how our systems will ultimately behave until we have fully constructed them and exhaustively probed their functions through test execution. No amount of upfront rigour, no depth of planning, no elite cadre of technical talent can circumvent this embarrassing limitation.

Embracing status determination is an admission that our vaunted processes and highly-skilled practitioners are profoundly inept at the core challenge of developing software systems that accurately model their specified behavior from the outset. We are hopelessly beholden to this retroactive “validation” step, owing to our rudimentary inability to wrangle the demons of complexity upfront through our hubris-laden and woefully inadequate practices.

Status determination stands as an unavoidable, perpetual reminder that for all our pontificating about engineering maturity and advancing the software discipline, we remain disappointingly crude in our approaches. It is the ceaseless tax we pay for failing to evolve more predictable, more reliable development techniques befitting a truly modern, professional field.

The Path Forward

Does this mean our development practices are fatally flawed? Pretty much. It means we have to allocate appropriate time and resources to status determination as a key part of our delivery lifecycle. We might better choose to strive to improve our processes. Let’s call software testing what it is – “status determination” – and double down on getting better at no longer needing it.