Difference between revisions of "PAIR UP"
Jump to navigation
Jump to search
(Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................") |
m (Topic titles in capital letters) |
||
| Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span><br /> | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span><br /> | ||
| − | =<span style="font-size: 16px">Pattern summary</span>= | + | =<span style="font-size: 16px">'''Pattern summary'''</span>= |
<span style="font-size: 16px">Let less experienced team members pair up with more experienced team members.</span> | <span style="font-size: 16px">Let less experienced team members pair up with more experienced team members.</span> | ||
| − | =<span style="font-size: 16px">Category</span>= | + | =<span style="font-size: 16px">'''Category'''</span>= |
<span style="font-size: 16px">Process</span> | <span style="font-size: 16px">Process</span> | ||
| − | =<span style="font-size: 16px">Context</span>= | + | =<span style="font-size: 16px">'''Context'''</span>= |
<span style="font-size: 16px">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.</span> | <span style="font-size: 16px">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.</span> | ||
| − | =<span style="font-size: 16px">Description</span>= | + | =<span style="font-size: 16px">'''Description'''</span>= |
<span style="font-size: 16px">Let new or not so knowledgeable team members pair up with more experienced team members when doing some test automation task.</span> | <span style="font-size: 16px">Let new or not so knowledgeable team members pair up with more experienced team members when doing some test automation task.</span> | ||
| − | =<span style="font-size: 16px">Implementation</span>= | + | =<span style="font-size: 16px">'''Implementation'''</span>= |
<span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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. </span><br /> <span style="font-size: 16px">Pairing testers and automators helps them understand their respective issues</span><br /> <br /> <span style="font-size: 16px">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.</span> | <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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. </span><br /> <span style="font-size: 16px">Pairing testers and automators helps them understand their respective issues</span><br /> <br /> <span style="font-size: 16px">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.</span> | ||
| − | =<span style="font-size: 16px">Potential problems</span>= | + | =<span style="font-size: 16px">'''Potential problems'''</span>= |
<span style="font-size: 16px">Managers may see two people working on the same thing as wasteful. You may need to point out the long-term advantages.</span><br /> <span style="font-size: 16px">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.</span> | <span style="font-size: 16px">Managers may see two people working on the same thing as wasteful. You may need to point out the long-term advantages.</span><br /> <span style="font-size: 16px">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.</span> | ||
| − | =<span style="font-size: 16px">Issues addressed by this pattern</span>= | + | =<span style="font-size: 16px">'''Issues addressed by this pattern'''</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">[[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 add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!</span><br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span></div> | <span style="font-size: 16px">If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!</span><br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span></div> | ||
Revision as of 14:48, 29 April 2018
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
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, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns