Background
The original approach was that the developers completed tasks and then passed them onto the QA engineers who then tested and performed releases. Whilst this approach worked overall there were a few issues that came up:
- Testing backlog caused by developers completing stories early but not being involved after the developing and review stage
- Quite often we had multiple tickets from the same developers in the ‘testing’ and ‘ready for testing’ column
- Developers would run out of things to do and pick up work from the next sprint which exaggerated the problem as at the start of the sprint there was an overhang from the last sprint with new tickets going straight into ‘ready for testing’
- Usually led to what felt like a mad dash to get tickets over the line
- Any absence with the QA engineers exaggerated the above disproportionately
Discussion
This came up in numerous retrospective meetings as an area that we wanted to improve. The key points raised were:
- As part of the dev-ops approach, developers, and teams to take more control of their releases
- We wanted developers to be more involved in the testing process so that they had input into each stage of the development process
- Having the developers able to help pick up testing tickets would help reduce the risk of having a bottleneck at the testing stage and free our testers up for other tasks
- We wanted to reduce the risks caused by any absences within the team
Solution
Once it was agreed that the developers would take more responsibility for testing, we agreed on the following approach:
- Initially, we started the developers out on the smallest tickets i.e text or style changes that could be quickly tested
- This was done during the planning session where we would nominate tickets by adding an asterisk to flag that the ticket was for the developers to pick up from the ‘ready for testing’ column
- Also during planning for each ticket, we’d discussed as a group what level of testing is required
- Over a few sprints, we gradually increased the complexity of the tickets the developers would test
- Finally, we stopped flagging individual tickets so that anyone can pick up a ‘ready for testing’ ticket if they are free
Results
We’ve found we are far more consistent in achieving sprint goals and throughput of tickets throughout the sprint, with fewer peaks and troughs of activity resulting in us burning down better. Having more members of the team available for testing has reduced feedback loops for tickets and given more cover for urgent testing and releasing when we receive last-minute requests.
Related Resources
