Difference between revisions of "PAIR UP"
m (Topic titles in capital letters) |
|||
(One intermediate revision by the same user not shown) | |||
Line 15: | Line 15: | ||
''<span style="font-size: 16px">[[KNOW-HOW LEAKAGE]]</span>''<br /> ''<span style="font-size: 16px">[[LIMITED EXPERIENCE]]</span>''<br /> ''<span style="font-size: 16px">[[UNAUTOMATABLE TEST CASES]]</span>'' | ''<span style="font-size: 16px">[[KNOW-HOW LEAKAGE]]</span>''<br /> ''<span style="font-size: 16px">[[LIMITED EXPERIENCE]]</span>''<br /> ''<span style="font-size: 16px">[[UNAUTOMATABLE TEST CASES]]</span>'' | ||
=<span style="font-size: 16px">'''Experiences'''</span>= | =<span style="font-size: 16px">'''Experiences'''</span>= | ||
− | <span style="font-size: 16px">If you have used this pattern, please | + | |
+ | <span style="font-size: 16px">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.</span><br /> <br /> | ||
+ | |||
+ | |||
+ | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span></div> |
Latest revision as of 14:40, 21 August 2018
Pattern summary
Let less experienced team members pair up with more experienced team members.
Category
Process
Context
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.
Description
Let new or not so knowledgeable team members pair up with more experienced team members when doing some test automation task.
Implementation
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.
Potential problems
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
KNOW-HOW LEAKAGE
LIMITED EXPERIENCE
UNAUTOMATABLE TEST CASES
Experiences
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.