Are testers really necessary in Scrum teams? After working on several projects, I have found 4 big reasons why they should be included from the first Sprint Planning.
While it is true that in theory The Scrum Guide points out that “Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis”, those of us who work in this Agile world know that Scrum itself, in an organic way, know that involving all roles that make a development possible is the key to success.
Scrum recognizes the importance of each member (not only developers) as part of the team. So, what actually happens to testers if Scrum suggests that an Agile team is fully capable of performing different tasks while being responsible for quality? Are they really necessary?
Thanks to the results we have achieved in several projects, I have no doubt that THEY ARE, and they are absolutely necessary from day 1 from the first Sprint Planning!
There are many ways to face testing in an Agile team that works with Scrum, especially when there are one or many testers. After years of working with this methodology, we have implemented a practice that has worked very well for us in Agile projects that have testers: discovering the most relevant test cases from the Spring Planning.
What is it about?
We know well that during the Sprint Planning, the Product Owner presents a prioritized list of User Stories and proposes an objective for the Sprint. For their part, the team reviews that list of requirements, asks the necessary questions, and establishes their acceptance criteria by mutual agreement.
Once all the information is available, the team estimates each User Story and breaks it down into specific tasks in order to task out the Sprint Backlog.
At this point, we propose that from the first Sprint Planning –and as part of the understanding of each User Story and the fragmentation into tasks– the main test cases that must be made on that User Story are included. What do we accomplish with this?
- Testing activities are now part of the User Story and are not independent of it.
- The titles of the discovered test cases are noted in the User Story and are complemented with a more robust description of that User Story.
- We do not leave the responsibility of testing solely in the tester’s hands. The task becomes an activity agreed on by the team, so the responsibility is shared.
Now, before explaining the benefits of including testers from the planning stage, let’s take a quick look at the Agile Testing Manifesto that inspired us to implement this practice.
Why do testers fit in perfectly from the first Sprint Planning?
Having seen how testing and Scrum can work together to gain productivity and improve the quality of development, here are 4 great reasons I found why a tester should be part of the Sprint Planning:
1. Higher quality of test cases
By promoting healthy discussion among the team for the definition of test cases, we result in a better quality of such test cases. We previously used to leave that job to the tester when he did his task of “writing the test cases” in each User Story. The tester can now focus on the other remaining test cases and of course, on the design, writing, and execution.
2. Better understanding of User Stories
The exercise of having the whole team think through the most important test cases raises questions, alternative paths, and analysis of all conditions. Thanks to this, we achieve a more complete and wide understanding of User Stories.
Thinking about how each User Story is going to be tested helps us understand better and more fully what should be done and what the client expects from us.
3. More precise estimations
As a result of the above, we found out that we get much more accurate estimations and that it is easier to size up the testing effort required by those who are not testers.
Thanks to this, the estimation techniques (Planning Poker) are more precise (fairer, if we prefer) if we take into account that previously the testing effort was not so easy to size up, for example, for a developer.
4. Teamwork and communication
Despite working with Scrum, we felt that the testers were separated from the team, that the developers did not know much about what the testers were working on, and that testing was becoming a bottleneck towards the end of the Sprint. The testers could not cope with executing all the test cases and managing the back and forths of the defects.
This situation only led to the accumulation of work and in the worst case, put the success and quality of the delivery at risk.
Having testers from the Sprint Planning helps us to better integrate and communicate between developers and testers from the very beginning of the Sprint (the Planning), which also helps us to achieve more accurate estimations and to ensure that everyone has some of the testing tasks as part of their responsibilities.
It is important to note that the execution of test cases –previously written and designed by the tester, who is the one that has specialization and responsibility– can now be implemented by any member of the team, especially towards the end of the Sprint when the testing work is greater, and the developers’ work decreases.
With this, one of the most difficult theoretical aspects of Scrum to carry out is materialized, mainly when there are specialists in the teams and any team member is able to perform any task.
To Sum Up
Testing in Scrum is not a myth, it is a reality for us. Including testers from the Sprint Planning has been a good practice that has helped us improve the quality of the software we build.
Content related: Agile management: 5 Scrum myths to see closely
Without a doubt, by having a better understanding of the requirements and which test cases to work on, we have been able to improve quality, increase productivity, and be more efficient, thanks to the elimination of the bottlenecks that used to arise at the end of the Sprint.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.