Difference between revisions of "LAZY AUTOMATOR"

From Test Automation Patterns
Jump to navigation Jump to search
m (Topic titles in capital letters)
Line 22: Line 22:
 
''<span style="font-size: 16px">[[MANUAL MIMICRY]]</span>''<br /> ''<span style="font-size: 16px">[[STALLED AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[ TEST DATA LOSS]]</span>''<br /> ''<span style="font-size: 16px">[[ TOOL-DRIVEN AUTOMATION]]</span>''
 
''<span style="font-size: 16px">[[MANUAL MIMICRY]]</span>''<br /> ''<span style="font-size: 16px">[[STALLED AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[ TEST DATA LOSS]]</span>''<br /> ''<span style="font-size: 16px">[[ TOOL-DRIVEN AUTOMATION]]</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 /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span><br /> <span style="font-size: 14px">B8</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 /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span>

Revision as of 09:07, 26 June 2018

.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns

Pattern summary

Lazy people are the best automation engineers.

Category

Process

Context

This pattern helps you start and keep efficient test automation and should be applied for big and small automation efforts.

Description

Why are lazy people the best automation engineers? They are too “lazy” to do the same boring job over and over again. Instead they devise ways to shortcut it with help from scripts or tools and profit from common good practices. Whenever they find themselves (or someone else) repeating a task, especially if it is "mechanical" in nature, it could probably be automated (provided it doesn't take too much effort).
For a “lazy automator” the focus is not only on building efficient testware but also on always keeping in mind that this testware has to be maintainable. Will he or she be able to update this testware six months from now with only a minimum of effort?

Implementation

Since what you have to automate varies from application to application, there can be no general solution; what is important is to be aware that there usually is a more efficient way to do something.
The following patterns are crucial in making your automation process and your automation testware efficient:

  • ASK FOR HELP: don’t waste time trying to do everything by yourself. If somebody knows better, do not hesitate to ask for help.
  • DON'T REINVENT THE WHEEL : if a problem has already been solved, then make the solution yours and go on from there.
  • THINK OUT-OF-THE-BOX: The best automation solutions are often the most creative.
  • Design MAINTAINABLE TESTWARE, which means that you should adopt GOOD PROGRAMMING PRACTICES and a GOOD DEVELOPMENT PROCESS.
  • See that you can draw on DEDICATED RESOURCES: if the test automation team members are jumping from one project to another, they will not be as effective as they could be. A lot of time will be wasted, and not only for the test automation project, just trying to remember where they stopped and what comes next. Also if you don’t have exclusive use of the machines you need, it may be much more difficult to get the initial conditions right, because other developers or testers will corrupt your data over and over again.
  • LOOK FOR TROUBLE: Keep your eyes open for possible problems; the sooner you spot them, the easier it will be to solve them.
  • Try to adopt TOOL INDEPENDENCE: sooner or later your SUT will change in a way that renders your current test tool obsolete. Or your tool will not be supported any longer and the next tool, even if developed by the same vendor, will not be compatible with the old one. If you keep your dependencies on the tools to a minimum, you will be able to face such events without having to start again from scratch.

Potential problems

We say that the automator should be "lazy", but only in the sense of not wanting to repeat actions that could be automated.
Sometimes in trying to achieve that goal, automators might become so fixated on trying to automate something, that they don't realise how much time they have spent on it, and this can be wasteful. It is only a net gain if it can be automated at a reasonable cost (in effort and time).

Issues addressed by this pattern

MANUAL MIMICRY
STALLED AUTOMATION
TEST DATA LOSS
TOOL-DRIVEN AUTOMATION

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