In two previous posts, When Developers and Testers Collide and Defending Your Position, we discussed the challenge Agile teams may have when shifting testing activities from a period of time after development is finished to become a collaborative activity occurring as close to the point of development as possible while the team is working in a timebox or sprint.
For many organizations, this experience of bringing testers and developers together during an Agile transformation can be a bit turbulent. The techniques, practices, and communication methods from previous methodologies create a resistance for the well-intended quality message coming into the team from a tester.
So, how can we make this transition smoother? Let’s walk through a typical sprint example and highlight a few key areas to focus on.
Testers are performing two activities:
1 – Writing Test Scenarios. Early in the sprint, testers are spending much of their time authoring test scenarios (or test cases) to meet the acceptance criteria for each story. This activity will begin to taper throughout the sprint.
2 – Running Test Scenarios. If testers are performing manual testing, they will begin to ramp up the execution of their test scenarios as development of the user stories increases. If automated testing is being performed, testers (or test engineers) will begin to create and run their scripts. For both testing approaches, the target is to complete them by the end of the sprint.
Throughout the sprint while they are performing both activities, testers should be infusing the team with conversation about quality and craftsmanship. Here are a few starting points to begin introducing these conversations:
A. During the planning session. The conversations should be centered around the acceptance criteria for each user story. A team should never leave a planning session without complete team alignment about what is to be built and tested for each user story. The voice of the tester must resonate at this time. This can be done by walking a team through The 5 Stages of User Story Sizing.
B. During test scenario authoring as stories are being developed. This is often the hardest conversation for the tester to introduce. For developers using Test Driven Development or considering their unit test approach, have the tester sit with the developer to discuss fringe cases and share past testing experiences from similar applications or environments. Having developers share their thought process as they begin coding is valuable input for the tester.
C. During test scenario execution as stories are nearing completion. As tests are being run, the tester should provide feedback to the developer with real-time communication. Based on these conversations, if something cannot be fixed right away a task can be added to the story and the task wall.
D. During the sprint review. The conversation about quality should be anchored around a “Definition of Done” or something similar such as “The Checklist Manifesto.” Any story not “done” will be withheld from the sprint review and introduced back into the backlog for future consideration. The temptation here is for the conversation to be “development is done so let’s go ahead and demo it” but the team must stay true to their commitments and each other.
E. During the retrospective. Open dialog around any gaps in quality should be introduced into the retrospective. This conversation should include identifying product-level gaps (what we created) and process-level gaps (how we created it).
If your team is struggling with quality and craftsmanship, start by focusing on these conversations as some (or all) may be missing or not robust enough to change the behavior of the team. As unpopular as it will be, the team may need to commit to fewer stories until these conversations become a natural part of team rhythm.
2 replies on “The Tester and Conversations About Quality”
Great overview, thanks Len. I think testers still will continue to struggle within projects where you may not have all the right resources with skills available in a timely manner – delays will likely occur due to competition for those scarce resources. For example, in my project my tester is “ready to go” but the environment is shared, used by and owned/operated by another team – they have their own agenda and timing which does not align with our timeline, hence delays and inefficiencies. It’s systtemic at the organization I’m in, so likely will not be able to change that mindset – all i can do as a scrum master is communicate and do what I can to remove those impediments of resource constraints.
[…] The Tester and Conversations About Quality: Len Lagestee (@lagestee), Agile Coach and blogger at llustratedagile.com, talks about Quality with Testers. […]