I want your tests!

Programmers usually dislike testing.

With waterfall projects it was easy for them to just disregard testing as it was done at the very end of the project and usually by different teams.

Martin Fowler came up with a great analogy to explain the importance of testing. It's called technical debt.

Put in a few words, test early or it will cost you.

Think you are making a loan to your bank to build this house you want. You'll be able to get it quick but you'll end up paying twice the price once you add the interest.

Testing is the same, you can disregard it to go faster, but in the end it will be much more expensive.

This is rather natural when you think about it.

If you test your code just after having written it and it fails you'll know which part is involved. It will be fresh enough in your mind that fixing should be done in a matter of minutes.

If you do that at the end of a waterfall development you'll have no idea which part of the code is involved and you'll probably won't remember how you did the trick.

There's a programmer's joke which says:

//When I wrote this, only God and I understood what I was doing
//Now, God only knows

Your probably get the idea what you'll be facing...

The good thing is that testing early is now more and more widely accepted as a good practice.

What I'm more interested in is automatic testing. I've met quite a few teams finding that hard to do and not getting the point of doing it automatically.

The fact that Scrum says nothing about engineering practices explains testing is quite often overlooked.

This is the reason why the teams getting the best results are often complementing Scrum with XP.

Well the first argument for automatic testing should please most programmers.

If you dislike testing then why not let the computer do the task?

Actually you wouldn't be testing any more but writing testing code. You could go back to the beauty of pure coding...

The true argument though is tied to what you want to achieve with Agility.

With Agile projects you want to get two things:

A working software (which is the reason why you want to test early and often)

The ability to respond to change (which is the reason why you want to automate testing)

Indeed if it takes you a full day to test your whole software each time you change something, your ability to embrace change will be quite limited.

The more frequent changes you would make, the more danger you would add to the project. You could end up being in a situation where you don't have working software anymore very fast!

However with automated testing (part of the build process and ideally no longer than 10 minutes) you are safe from side-effects of change.

Now you see how you can be flexible, fast and still maintain working software!

Credits: Original design by N. Lochet (based on J. M. Flagg 1917' poster)