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.
good point george, it’s all a matter of planning and collaboration. If you make testing a shared responsibility amongst devs and testers you can bridge the gap. If testing is getting behind you can introduce rules such as demanding tests to be available before a story can be be picked up. This will make it very clear when testing is becoming a bottleneck. Another one is to make devs responsible for creating the fixtures first (in collaboration with testers). It’s not that difficult, just has to become routine.
This problem seem to be a concern for many teams that are trying to adopt Scrum. the solution you propose, i.e. automated testing is the only proposed solution that I think I have ever read about. So basically, to get the flow in development as you describe where stories are completely done before new stories are started, you need to have automated tests in place.
However, the Scrum guide etc. does not say ONE WORD about automated testing etc. Would you say that Scrum or other agile method is impossible without automated testing and if not how can this continuous flow be accomplished without automated testing?
Fredrik, the Scrum Guide says nothing about creating software. It only describes managing the process.
The alternative to automated testing seems to be lowered expectations. If you don’t mind going very slowly, and accepting lesser quality, then Scrum can still bring benefits over some other ways of developing software.
Almost three years late…
I would like to know what kind of automated tests we’re talking about?
Key-word driven test, like Selenium, or unit tests that will only interact with code (not the html and css).
Hi, Vlr,
In this posting I’m talking about tests from the point of view of the business. They can be implemented in many ways: through the GUI, through another API, or directly to some code module.
In general, I recommend doing most testing at the lowest level possible, and a little bit that makes sure things are wired up correctly.
Available in French translation at http://www.les-traducteurs-agiles.org/traductions/des-testeurs-a-la-traine.html