TOOL-DRIVEN AUTOMATION

From Test Automation Patterns
Revision as of 09:23, 26 June 2018 by Seretta (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues

Issue Summary

Test cases are automated using “as is” the features of a test automation tool

Category

Process

Examples

In older tools this means using the capture functionality to develop test cases: while a test case is executed manually the tool records all the tester actions in a proprietary script. By replaying the script the test case can be executed again automatically (look up the pattern CAPTURE-REPLAY for more details).
In more modern tools you can record "keyword" scripts, but the mode of operation is actually much the same as in capture-replay.

Both approaches harbour serious problems:
The speed and ease in recording test cases can induce testers to record more and more tests (keyword scripts), without considering GOOD PROGRAMMING PRACTICES such as modularity, setting standards and so on that enhance reuse and thus maintainability. Without reuse, the effort to update the automation in parallel with the changes in the SUT (System under Test) becomes more and more grievous until you end up with STALLED AUTOMATION.

Resolving Patterns

Most recommended:

  • TOOL INDEPENDENCE: Separate the technical implementation that is specific for the tool from the functional implementation.
  • GOOD PROGRAMMING PRACTICES: Use the same good programming practices for test code as in software development for production code.
  • LAZY AUTOMATOR: Lazy people are the best automation engineers.
  • TEST AUTOMATION OWNER: Appoint an owner for the test automation effort
  • TESTWARE ARCHITECTURE: Design the structure of your testware so that your automators and testers can work as efficiently as possible
  • WHOLE TEAM APPROACH: Testers, coders and other roles work together on one team to develop test automation along with production code


Other useful patterns:

  • LOOK FOR TROUBLE: Keep an eye on possible problems in order to solve them before they become unmanageable
  • MAINTAINABLE TESTWARE: Design your testware so that it does not have to be updated for every little change in the Software Under Test (SUT).
  • SET STANDARDS: Set and follow standards for the automation artefacts.
  • GET TRAINING: Plan to get training for all those involved in the test automation project


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