Why testers fear Agile Development
October 28, 2007
Let’s assume (for the sake of this argument) that the programmers can build one small idea in the first week. Then a second small idea in the second week. They even have time enough to fix the few defects they introduced in the first week. Let’s say they can sustain that pace forever.
The program grows steadily. But what happens to testing?
Manually test each iteration
If we manually test each finished idea, the diagram above is what’s going to happen. That’s because we have to make sure all previously built ideas still work properly. Obviously it wouldn’t take long for testing to cost a lot more than programming. And it’s almost certain that at one point in the future, the testing will not be done, when new software is ready.
So that doesn’t work.
Manually test each release
Why not wait for a while, and then test a set of ideas together - so we only have to test them once. That’s what’s going to happen:
Because there is more and more software, tests will take longer and longer.
With all defects of 6 iterations found, the programmers won’t be able to work on a new small idea for a week. So the 12 ideas that could have been done in 12 weeks are now done in 13.
Progress is getting slower and slower. That’s not what Agile promises or is about.
No Manual Testing
That’s why automatic tests are crucial for Agile development. There is no way around it. If you want to make steady progress, you need automatic tests.
It’s the teams responsibility to make sure it has sufficient automatic tests. There is no test department doing that.
No testing phase = no testers?
If the testing phase doesn’t exist anymore, where are the testers? And that’s (one of the) reason(s) why I think a lot of testers don’t like Agile development.
I believe that testers will need a different skill set than now. They will have to work more closely with customers - helping them discover untested areas. Helping them break down big ideas into smaller ideas. Helping programmers figure out a way to test something automatically, that is particularly hard to test automatically.
But once they do all that - they aren’t testers anymore. They are team members. And that’s what they always should have been.
…now this is a theme close to my heart…
The whole idea that “testing” can provide an Agile pattern of solution is quite novel and challenges people’s pre-conceived ideas about how “testing” works on a project.
There are some fundementals around FUNCTIONAL Automated Testing (NOT unit testing!) that have to be accepted and the automated testing approach has to be blended (in my view) with manual and other forms of testing in order to get what all projects ACTUALLY want, a strongly positive outcome at the deployment point.
This topic deserves a whole thread… [:o)
Dave