Monday, August 27, 2018

What do testers in agile teams do when there is nothing to test? | SupremeAgile

In the last eight or so years I have been involved in more than 50 agile transitions as an implementer, trainer or consultant. Each transition encounters its own challenges and complexities, which of course 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 that they can deliver to test in the first few days (or more) of the iteration.

Well, I think that 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. (For more information, please read my previous article here.) Unfortunately, in many cases, testers have neither the knowledge nor the skills or willingness to make this transition.

In this case, I will say that the tester should be preparing for tests at the user-story level, which include the test strategy and test methods to be used. Additionally, they should prepare test environments, so when there is available code to test, the test process can start immediately.

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, if the team spends time trying to identify and estimate each one of the non-programming tasks during the sprint planning meeting, 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:
  1. Break down user stories into tasks.
  2. Talk to external resources that can help the team (such as designers and tech experts).
  3. Help the team handle impediments.
  4. Writing test scenarios.
  5. Investigate new automation tools.
  6. Set up a test or development environment.
  7. Improve the development and testing processes.
  8. Improve the build-creation processes.
  9. Document checklists, health-checks, release notes, etc.

The tester as bottleneck

Up till 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 prior to the end of the sprint the tester receives stories to test without having a real chance to test everything. What do we do now? Well, we can remove this bottleneck by involving all team members in the testing process. The tester decides which tests to do himself, 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 is using 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? Well, the tester should pair-program with the developers that 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. 

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

No comments:

Post a Comment

My Presentations