Rennebo

This article is based on my experience with integrating Testers in Scrum Teams. By reading this article you won’t get the silver bullet to solve all Scrum Testing challenges, but you will get inspiration on how it can be done.

Most software developers aren’t used to interact directly with testers, and even if they are, the tester is rarely made part of the daily work. If you don’t want a continuous tale of corrections to previous Sprint Releases – and thereby break the natural circle of progress, you will need to make the Tester play a natural and integrated part in the Scrum Team.

The traditional testing approach

The traditional approach for utilizing Testers on a project is to have the Testers design the test cases based on the documented requirements combined with the solution design document. The Testers then conduct the actual testing when the software has been developed.

The mindset behind this process is the same as laid the foundation for waterfall software development; meaning that work is carried out in a controlled process, where the need for adaption to change is ignored.

Even though Scrum has been around for many years now, it is still unnatural for most teams to utilize Testers as integrated members of the Scrum Team. Even Teams, who officially have a Tester as a member, have a tendency to only involve the Tester as someone who verifies what the code actually work as the developers intended.

Setting the scene

In order to change the behavior of the team, and make the Tester a natural part of the team, you will need to make it clear how the Tester can help the team, instead of being an impediment.

Step 1 Stop accepting “Remaining Estimates” from the team and introduce a calculation instead. By doing this, you will replace “Wishful thinking” with statistical analysis, and thereby make it really attractive for the Team to complete testing early.

The approach I have been using for calculating the Trend Curve on the Burndown Chart is based on the following formula:

Current state = [Total Story Points in Sprint] – ([Points on Open tasks] * 0% + [Points on tasks in progress] * 50% + [Points on Done tasks] * 100%)

Step 2 Explain to the Scrum Team how the Burndown chart will look if they only do testing at the end of the Sprint.

For further arguments on this step, please read the article “The No-Sex-Curve” of Scrum”.

Step 3 Introduce the team to a different approach and make them discuss how they can optimize the inclusion of the Tester and get things verified “on the fly”.

Recommended implementation

Throughout my time coaching Scrum teams, I have found that the following approach not only introduces a mentality change, but also works well as a continuously improving process.

The model is not a replacement for continuous dialogue, but it will help the process succeed.

The suggested approach is not a theoretical exercise. If the Team focuses on the purpose of the process, the clarification process can be completed in a matter of minutes.

Drawing explained:

1. A developer picks a task from the board during the Daily Scrum. This part hasn’t changed compared to “normal”.
2. After the developer has thought about how he is going to implement the solution, the developer then explains the solution to the Tester.
3. The Tester and Developer then discuss how the suggested implementation will help the Team deliver the Sprint successfully.
4. If relevant, the developer elaborates over the discussion with the Tester and provides a modified implementation idea.
5. The Tester and Developer agrees on an implementation, and how it will be tested.
6. The Tester starts writing the actual Test Cases needed to verify the suggested solution, while the Developer implements the solution.
7. The Developer hands over the implementation to the Tester, who then executes the already prepared Test Cases.
8. The Tester moves the task to Done

By implementing this simple routine, you should experience increased Quality on the Sprint deliveries, and thereby get a more lean Scrum implementation.