The testers get behind at the end
It’s a very common complaint, such as this one left on the Scrumdevelopment yahoogroup:
Usually in different phases, workload for tester and dev is different. E.g. when a project is coming to the end, most of the tasks will be test.
There are a couple of big red flags waving at me in those two sentences. One is “different phases.” Why should a software development project, especially one only a couple weeks to a couple months long, have phases? The other is, at “the end, most of the tasks will be test.” Postponing testing to a phase at the end has never worked very well. It always results in the testers being behind at the end.
Does this situation sound somewhat familiar to you? If so, what can we do about it?
Many teams try to live with it. I’ve seen teams institutionalize “being behind” by implementing in one iteration and testing in the next. When they do that, they generally find that problems are found in the testing, so the implementation really drags across two iterations. The rework in the second iteration bumps new work planned for that iteration, so things continue to slide. And since it’s hard to tell when a bit of work really is completely done, it’s hard to know how much work fits into an iteration and when the release will be ready. Often things feel the same as they did before going to time-boxed iterative development. That’s no surprise, because this really isn’t time-boxed iterative development. It’s waterfall phases in sheep’s clothing.
Just don’t do it. Get things completely done and tested before moving on to the next thing.
But how? Don’t you have to wait until the code is written before you can test it?
No, you don’t. Start when the product owner is describing what is to be done. Distill that down to the essence of the user story. Make sure that the product owner agrees that this potentially automatable distillation is what is desired.
Then, while the developers are hard at work implementing the functionality, the testers should be automating the test that verifies it. To be sure, this is often something the testers, and the organization they work for, find unfamiliar. It’ll go a little slow and shaky while you learn. It’s completely understandable that testers will need some assistance from the developers as they automate the tests–after all, test automation is a form of programming.
The bottom line is that the story isn’t ready for acceptance until both the implementation and the test are done, and the test passes. That’s the minimum, but take a further look, too.
Over time, this will get easier. The testers will learn to do more test automation with less help. The resulting set of regression tests will grow, giving quick feedback that functionality that worked before, still works. Instead of the testers getting further and further behind as they continue to check the same functionality iteration after iteration, they’ll get further ahead because running these tests takes about the same amount of time. They’ll have more time to do exploratory testing, and less of that exploratory testing will have to cover basic functionality.
It’s hard work to make automated acceptance testing a success. In the end, though, it’s the only thing that can make testing a success in time-boxed iterative development. If you don’t make it work, I guarantee the testers will get further and further behind.