Agile gets everywhere and it is not easy. It takes time. It takes practice. What will a tester do?
Everyone on the team has to adapt to the particular dynamic on the team - and that includes testers - so answering questions like “What should a tester do on an Agile project” becomes really hard.
I can think of some things that a tester will probably have to do, and I can think of some things they will probably find consistently hard, but I can’t give an absolute answer to that question. I expect every team to evolve over the time they work together, so the dynamic, and their approach to working in that dynamic, should change over time.
So in addition to ‘doing’ testing, a tester will probably have to:
- remind people that the story estimate needs to include time to test it
- draw out of the BA or User acceptance criteria for each story
- identify ambiguity in the acceptance criteria fast and early
- remind people to identify ’examples’ to support the story discussions and acceptance criteria
- critically analyse the story and acceptance criteria for any ‘risks’ that may require additional testing or additional criteria in the story
- make an estimate of how much exploration around that story they currently think they will require
- figure out automation options for acceptance scripts on the story
- add additional stories for testing the relationships between stories
- add additional stories to allow investigation into risks they they start to spot e.g. security, stress, risk, performance, testability, integration
- think about how the stories interrelate and figure out ways of checking their interdependencies
- work with the development team to understand and extend the scope of the unit testing
- making sure people think about the ‘data’ used in the tests, not just code coverage
- continually find ways of extending the acceptance automation, find more ‘cost effective’ and bang for the buck automation, find ways of making that automation work faster
- mentoring the other members of the team in ’thinking like a tester’
Things they will probably find hard include:
- adding value with exploration without going too far outside the bounds of the story
- getting ‘it all done’ within the iteration
- convincing ‘some people’ outside the team that they ‘add value’
- avoiding getting sucked into a story and maintaining a ‘release’ view, ‘iteration’ view and ‘story’ view when thinking about testing
I do not consider the above lists complete and welcome your additions.
Anyone that joins an ‘Agile’ project without the ability to adapt their approach to the needs of the project will fail to add as much value to the project as they could. Testers run the risk that other team members may expect less of them, in terms of their ability to adapt, and allow them to add less value than they could. Testers need to work to avoid this situation. And if they do, they will probably enjoy the experience of working on an Agile project.
If you are looking for the Evil Tester Explains Agile Testing Comic, then look here.
