KNOW-HOW LEAKAGE

From Test Automation Patterns
Revision as of 08:40, 5 April 2018 by Cathal (talk | contribs) (Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
.................................................................................................................Main Page / Back to Management Issues / Back to Test Automation Issues

Issue summary


Test automation know-how (for instance scripting, tools) is being lost from the organisation.

Category


Management

Examples


  1. Test automation was started by a "lone cowboy" who has left the company.
  2. High turnover of staff means that people never get into sufficient detailed knowledge about the existing automation before they move on (and no backup was planned).
  3. Test automation is shelfware and nobody knows what has been developed and where it has been stored.


Questions


Why are people leaving the team, the company?
Could someone who used to have good knowledge of the automation be called back to transfer knowledge to the current team? (as a consultant?)
Does it take too long to figure out the structure of the automation - is the architecture unclear?

Resolving Patterns


Most recommended:

  • DEPUTY: Appoint a deputy to all important knowledge carriers


Other useful patterns:

  • DOCUMENT THE TESTWARE: This pattern is essential for keeping the test automation effort maintainable
  • GET TRAINING: this pattern should be used regularly by the whole team
  • PAIR UP: apply this pattern to train newbies as fast as possible
  • SHARE INFORMATION: apply this pattern to solve this issue effectively

.................................................................................................................Main Page / Back to Management Issues / Back to Test Automation Issues