TOOL DEPENDENCY

From Test Automation Patterns
Revision as of 15:28, 4 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 Design Issues / Back to Test Automation Issues

Issue summary

Test automation is strongly dependent on some special tool.

Category

Design

Examples

  1. You have written all the automation scripts in the proprietary language of a particular capture-replay tool
  2. You have to change to a different tool, but now you can't run any of your existing scripts without major work.


Questions


How to make sure that if and when the tool will have to be changed, you don't have to start again from scratch?

Resolving Patterns


Most recommended:

  • RIGHT TOOLS: use this pattern if your present tool doesn't fit the Software Under Test (SUT) well enough
  • TOOL INDEPENDENCE: this is the pattern of choice to solve this issue


Other useful patterns:

  • ABSTRACTION LEVELS: this pattern helps you separate the technical tool layer from the functional test cases
  • OBJECT MAP: use this pattern with all tools

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