Someone asked me what should happen to the testers now that the developers were moving to Agile. How should they handle the new situation? This is how I answered:
I think your best bet would be to integrate with the development teams. Here are two things you could start thinking about:
- Backlog items need to be INVEST where T = Testable. Is it testable? Someone from your team needs to decide this. If it is not testable, you cannot accept that it enters the backlog, much less the sprint because you will look bad when you cannot deliver the tests. I have seen many occasions where T was not respected with the result that delivery could never be completed. Unhappy customer, unhappy team.
- I am sure that you are familiar with the V for verification? Your job is to cover the top part of the V, that is both \ and /, inside each sprint. That means that the job of the tester start on day 1 with analyzing the requirements and working with the customer to elicit the specific tests that are implicit in the requirement. This knowledge needs to be shared with developers throughout the sprint. No one should be “surprised” at the end of the sprint by the work that your team members provide.
- Often in immature teams “developers” have higher status than “testers” and thus any excuse to ignore testing aspects of a backlog item are received with happiness (confirmation bias). Until the team has reached a maturity level where it can leverage the multifunctional diversity, you need to make sure that testing is not ignored. These are generalist teams with specialist roles.
- There could still be an additional separate testing team for eg load and performance testing, penetration testing. The majority of the testing should be done in the teams, in the sprints.
Image sources
- 1280px Corvette Crash Tester cropped: Corvette Crash Tester Uploaded by Partyzan_XXI via Wikimedia Commons | CC BY 2.0
I have been working as tester for years, in different projects, but the common factor is that all of them as been agile.
As a comment to Gregers text I have to take an example from a group I worked with that used Scrum and was agile in its true meaning.
The first problem we saw with including the the tester in the Scrum team was their workload shifted from 0% to 200% during a 2 week sprint.
The first thing we tried was introducing Test Driven Development, TDD, and the tests was written in pairs developer & tester as a part in continues development. That helped some even though some testers raised the concern that they didn’t want to become developers.
So back to the drawing board by then when we had started to automate tests we used cucumber scripts that the testers wrote. Light bulb idea!
We then changed how a sprint was planned.
It all started with the story, the testers and the developers decided if it was a small, medium or big story after that the developers wrote the unit tests in TDD style and the testers wrote the Behavior Driven Tests, BDD, in Cucumber and the Definition of Done was updated to “A story is complete when it passed all the TDD tests and the BDD tests.”
This also meant that we could cut some waste, we decided that the source code with TDD and BDD tests was enough documentation for both developers and testers.
This meant that the workload evened out to be more like 100% during a two week period and the testers had the time to do negative, UX and UI testing, which raised lots of other issues but that is another story.
Thanks for the comment, Mattias. You are right, it is a very common warning sign that things are not being done right when testers have nothing to do until the end of the sprint. There is most likely a combination of two factors at play:
Yes sometimes the stories are to big but that has to be able to happen and this is a ongoing work for testers as well as developers to watch out for. If this is a part of the group it seldom leads to problems, the key is to let the testers grow and to be able to take a bigger part of the process.