We are currently starting with distributed Scrum Teams. We have one part of a team located in the Netherlands and the other part in India. The Dutch side of the team exists out of one functional designer, one tester, one technical writer and two developers. The India side exists out of two developers and two testers. I am not going to discuss the distributed approach in this blog, only the problem of the Dutch tester 😉
We use a lot of Exploratory Testing (ET) in our test strategy. We have created a standard ET Charter, the tester has to decide per product backlog item which items are relevant to test. You need a lot of knowledge of the application and of testing to do good ET. The testers in India are familiar with testing. However, not with ET and of course relative new to our software. The problem of the Dutch tester was: “How can I coach the Indian testers and not do all the ET again to verify their work?”
We discussed this problem in our Test Retrospective and came up with the following ideas for him:
- Accept that not all problems will be found;
- Use pair-testing;
- Select one item of the ET charter with tester X and discuss it, select another item of another ET Charter and discuss it with test Y;
Let me explain the ideas in more detail.
Accept that not all problems will be found
The only guarantee that you have when you deliver software that it contains bugs. You will never find all bugs for acceptable costs. If you hire a lot of testers, hire the best engineers, review all specs, etc., you have change of creating software without bugs. However, in most companies or projects this is not possible.
In our test strategy we have written that high risk items will be tested by the most senior tester of the team. The new Indian testers are not very experienced so they will not start testing the high risk items. The team selects it own work, that is part of Scrum, and will also select some simple features. The new Indian testers can be assigned to test the simple features, it is part of their training. The change that Developers introduce bugs is not that high and if so, the risk is very low because it concerns only simple features.
So we assign simple tasks to the new team members, the risk of introducing new problems is not high and the change of finding them is very high. In case a bug slips through it is no big risk for the customer because it is a low risk feature.
In a previous blog I wrote an article about pair testing. It is wise to use pair testing in combination with the next idea.
Select one item of the ET charter with tester X and discuss it, select another item of another ET Charter and discuss it with tester Y
We use a standard ET Charter as template for all ET testing. Standard features are tested with the same ET Charter and some configuration parts are used for in parts of our software. You could discuss every item of the ET Charter with every tester, this will cost a lot of time. However, an option is to select a certain item of the Charter and execute pair testing. The new tester is trained and learns from the experience of the senior tester. The new testers can transfer his knowledge also to his colleague in India.
The Dutch tester could test the same item with the other Indian tester. However, what is the value? Sure, the tester learns from the experience of the senior tester but the Indian tester that already did pair testing could also explain how to test the issue. We think it is more efficient to test another issue from the ET Charter with the second Indian tester. He can share his knowledge with his colleague tester, in this case you have trained two testers in India on different subjects.
It is no easy to train two new testers in a distributed Scrum team, that is located on the other side of the world. As (project/test/development/etc) manager you should be aware of the risk and accept that some problems will slip through. With good risk management done by the team, pair testing and efficient coaching you can train the testers as fast as possible on the job. In the end the most important issue is communication! If there is no communication between the testers every coaching model has no change of succeeding.