Five mistakes teams make with automated testing

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. These are the ones we run into repeatedly when we audit automated testing.

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.

The mistakes we see most

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Tests are how you change things without fear
• Cover the paths that lose money if they break
• Never checking whether the fix actually worked

A slow test suite is a suite nobody runs. In practice this is a scheduling problem more than a technical one. Assume whoever inherits this will have half your context and none of your patience.

A reasonable first step

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. 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.