Continuing with the metric fest, we calculated that throughout the last year, one of the projects accumulated more than 250 open bugs. That means that after removing the fixed new bugs, and fixed all bugs from the count, the team is far behind in catching up the runaway train.

What’s the solution?

There’s not one solution, but a complete mindset change, which I’m trying to push. But one of the tools we should use is test automation. Currently, all tests are manual, and are costly. There’s also almost no use of automated unit-tests.

So we’re missing a couple of things. One – we’re not even starting to build the safety net for tomorrow. With every day, new code is going into the pile, which makes the system more complex and harder to test, and so more bugs are creeping in. Automated tests can provide the safety net, if people used it.

The other side of the coin is the cost of manual tests. Working with instruments, there is no way we can replace all manual tests with automated. But look at it this way. Sanity tests (or smoke tests, choose your definition) are supposed to be run on each build. What happens when they take 2 days to run? That’s right, they are run less. So one of the other safety net tool for risk reduction is not used effectively.

Automation can at least provide the ability to provide the safety net, and have the test team concentrate on the bigger issues. The cost? A mindset change. And diverting precious developer time to test automation, which of course clashes with the “we’ve got to ship it by X” mindset.

Change is hard. I’m still confident though.