Difference between revisions of "CHECK-TO-LEARN"
| Line 25: | Line 25: | ||
=<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 and would like to contribute your experience to the wiki, please go to [[ | + | <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> | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[ Process Patterns]] / Back to [[ Test Automation Patterns]]</span></div> | ||
Latest revision as of 14:36, 21 August 2018
Pattern summary
Let new team members learn by checking the health of the existing automation testware
Category
Process
Context
Use this pattern to teach new team members what is already available to the test automation team. This pattern can be used in any context where new people have to be integrated in the automation team
Description
New team members have to learn what is already available and what are "the rules of the game". Asking them to check the health of the existing automation testware has two big advantages:
- people are positively motivated to dig in
- the check is done from a fresh point of view
- by comparing the existing testware with their own experience, newcomers can introduce new ideas, tools and processes
Implementation
Ask newcomers not just to learn how the tool works, but to check the testware. Some suggestions:
- are the testcases sufficiently documented?
- how easy is it to find scripts or data, particularly for reuse?
- how easy is it to write a new test?
- how easy is it to change a test if the software being tested has changed?
- how easy is it to find out what went wrong when an automated test fails?
They can keep track of how long it takes to do these tasks - the quicker and easier it is, the healthier the automation is.
Potential problems
Because the newcomers are (obviously) new, they may get a bit lost - but this is actually very useful information about the automation!
Be sure to emphasise that what is being investigated is the automation, not the person! (They don't "fail" the test, the automation does!)
Issues addressed by this pattern
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.