What do testers in agile teams do when there is nothing to test? | David Tzemach
Updated: Mar 2, 2022
In the last ten or so years, I have been involved in many agile transitions as an implementer, trainer, or consultant. Each change encounters its challenges and complexities, which has led to many questions from the business and agile teams.
One question that keeps coming up in almost all agile projects is: "What should testers do during the sprint when there is nothing to test?" This issue is often encountered. Think about the beginning of an iteration, when developers start coding, but there is no build they can deliver to test in the first few days (or more) of the iteration.
Well, in the current software industry, testers should know how to code in a way that allows them to add more value to their teams and stay relevant. Unfortunately, testers have neither the knowledge nor the skills or willingness to make this transition in many cases.
In this case, I will say that the tester should be preparing for tests at the user-story level, including the test strategy and test methods to be used. Additionally, they should design test environments, so the test process can start immediately when there is available code to test.
During the planning meeting at the start of each iteration, the team commits to the stories they intend to deliver at the end of the iteration. As part of this commitment, the team also estimates the work and starts breaking down stories into smaller tasks that they will use as part of their day-to-day activities.
Let’s focus on the task-breakdown process. During this process, the team usually tends to work on programming tasks. However, there are many other non-programming tasks that the team needs to accomplish during the iteration. Now, suppose the team spends time identifying and estimating each of the non-programming tasks during the sprint planning meeting. In that case, the chances are that the tester can contribute quite a lot, even if he does not have the necessary coding skills and there is no testing to do right now.
Let's see some examples of the non-programming tasks that often need to be done during the iteration:
Break down user stories into tasks.
Talk to external resources that can help the team (designers and tech experts).
Help the team handle impediments.
Writing test scenarios.
Investigate new automation tools.
Set up a test or development environment.
Improve the development and testing processes.
Improve the build-creation processes.
Document checklists, health checks, release notes, etc.
THE TESTER AS BOTTLENECK
Until now, we reviewed the common situation where the tester does not have anything to test during part of the sprint; conversely, the tester may become the bottleneck of the team. Think about the following scenario. A few days before the end of the sprint, the tester receives stories to test without having a real chance to test everything. What do we do now? We can remove this bottleneck by involving all team members in the testing process. The tester decides which tests to do and which tests should be delegated to the rest of the team. That's what cross-functional teams are all about!
TEST-DRIVEN DEVELOPMENT (TDD)
If the team uses TDD as their preferred software development process, it means that team members spend more time writing test code from day one. In this case, what value does the tester bring? The tester should pair-program with the developers who are writing the test framework for their code.
If the tester has the coding skills, he can do much more in TDD by helping the team write the tests, but if that's not the case, he should still pair-program with developers to suggest tests for better test coverage.
If the team is not using TDD, or if they've already written all the test cases that will be implemented by developers using automated tools, the tester should add value by simply doing whatever he can to help the team achieve the iteration goal, just as we’d expect to see from any other team member.