SHORT ITERATIONS
Pattern summary
Develop test automation in short iterations.
Category
Process
Context
This pattern is probably applicable for any context. Even if you are doing a large-scale long-term automation effort, it is worth using short iterations to develop it.
Description
Develop your test automation in short iterations. The charm of short iterations is that you get fast and regularly feedback to see if you are on the right track. You can keep managers steadily informed about progress, testers and developers get to see results quickly, all of which increases the opportunities to get more support for the automation project.
At the end of the iteration your customers, who in the case of test automation are testers and developers, can immediately tell you if your efforts went in the right direction. If not, it’s only the work of the past iteration that eventually gets scrapped and not the whole project!
Short iterations allow you to do automation that gives the best return at any point, so you are able to show benefits more quickly.
Implementation
As in Agile Software Development, you should first decide the iteration length (usually one or two weeks).
Then select for the iteration only as much work as can be completely finished, that is developed and tested.
At the end of the iteration (debriefing) you should examine what went well and what went wrong (LEARN FROM MISTAKES) in order to adjust the tasks in the next iterations. At this point you can also check to see what else could be improved, how well motivated the team are and address any problems.
Don’t forget to SHARE INFORMATION and to CELEBRATE SUCCESS
Potential problems
It may be difficult to see what should go into an iteration - it wants to be something significant rather than trivial, but not too big to be done in a short iteration.
Working in short iterations is very intense; many iterations back-to-back may lead to burnout.
Thinking too much about the content for iterations may take your attention away from "the big picture".
The work done in an iteration needs to be able to be absorbed by those using the results.
Issues addressed by this pattern
INADEQUATE SUPPORT
NO INFO ON CHANGES
SCHEDULE SLIP
UNMOTIVATED TEAM
Experiences
Jochim Van Dorpe writes:
In our agile project we let the test iterations fall together with the sprints. It's a project I inherited from an old-fashioned waterfall style without almost any (reusable) automation. So in every iteration I try to put some of the following:
- See that the cards (i.e. stories) from the sprint are DONE, with a sufficient amount of (automated) tests
- Automate some existing manual tests on some existing functionality
- Design and automate some tests cases of functionalities that weren't tested at all in the past.
If in the last (half a) day of the sprint, the developers are done with the cards for the sprint, they give a hand in automating some tests wich are reviewed by the test analyst later on. The developers do the same to increase their unit tests.
After each iteration we show the progress of the test project to the whole scrum group and discuss where we should dig in a little deeper. After all, bugs are social beings, so if one pops up, it's worth investigating a bit in its neigborhood.
Note:
If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns