Testing Is … A Huge Time Saver
The most common excuse I have heard for the failure to write automated tests is that there is no time. People have a deadline to hit, and it seems there is no time to waste writing test code when there are features that need implementing. To me, this is a terrible excuse. Not because I think that code without automated tests can’t provide your customers with valuable features. Rather, it is because you are going to have to test the features somehow, and if you can’t do it automatically you are going to have to do it by hand. As I mentioned in a previous post, I think that in the majority of cases this will be slower than just writing the automated tests.
The crux of the argument is that features never work the first time that you try them. I don’t know about you, but when my new code works the first time I try it I’m not happy, I’m suspicious. This suspicion comes from years of getting things wrong. Typically, each feature will take several testing iterations to get right. This is trivial with an automated test, and time consuming with a manual one. I have not measured the typical time for each alternative, but I would say that most of us naturally assume the manual testing treadmill is less time consuming than it turns out to be1. So, when we have that short term deadline to hit, automating the tests can be a lot more effective at saving time than we realise.
Over the longer term, the fact that automated testing saves time is pretty much a no-brainer. In fact, I would say that this is just one case of a general principle:
Over the long term, the right way is also the fastest way.
Cutting corners is at best a near-term win, and cannot be sustained. Over the long term, automated testing continues to pay dividends, with only the (hopefully) small cost of maintaining the test suite. The most dramatic time savings come when your automated test suite finds a new bug as it is introduced by a developer. With the right process in place2, this bug can be fixed before it breaks the stride of the development team, and long before it reaches a customer and leads to a costly support incident.
—
1 Perhaps a specific case of the general optimism that makes most of us terrible at estimating software schedules.
2 And tools!
This entry was posted on Tuesday, February 27th, 2007 at 1:37 am and is filed under Agile, Continuous Integration, Technology, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
