The real cost of ignoring automated testing

Teams tend to reach for this after something has already gone wrong. Nobody bills you for neglecting automated testing. The cost shows up somewhere else.

Most development decisions are really maintenance decisions wearing a different hat. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Where the cost lands

• Time spent on work that should not have been necessary
• Enquiries that quietly never arrive
• Tests are how you change things without fear
• Rework, once the problem is finally visible

Cover the paths that lose money if they break. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Where to go from here

A slow test suite is a suite nobody runs. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about automated testing before you move on:

• Someone can say what the current setup is without going to look
• Tests are how you change things without fear — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.