Let less experienced team members pair up with more experienced team members.
This pattern can always be applied, but is especially useful when team members are expected to learn new skills as fast as possible or to spread knowledge within the team.
Let new or not so knowledgeable team members pair up with more experienced team members when doing some test automation task.
In software development it’s called pair programming. Two developers sit together at one computer. One writes the code and the other looks on and reviews what the other is doing. They discuss eventual problems together. The one that is less experienced can learn very quickly how the more experienced developer writes code or solves some kind of issue.
In test automation it works the same way: for instance if a new person on the team doesn’t know the tools yet, by pairing he can learn by seeing what the other is doing. He (or she) can ASK FOR HELP directly.
By pairing you can spread know-how in the entire team so that if someone leaves the company, you will not feel the loss as badly.
Pairing testers and automators helps them understand their respective issues
Pairing is good not only for training, but also to work faster since it implies an immediate review of what is being done: quality is better from the start. It should be used every time non-trivial issues have to be solved.
Managers may see two people working on the same thing as wasteful. You may need to point out the long-term advantages.
It is important that the people working together have a good combination of support for each other and a "critical eye". If they don't get on well, they won't work effectively, but if they are too "nice" they will accept each other's work without challenging it.
Issues addressed by this pattern
If you have used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns