TOOL DEPENDENCY
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues
.................................................................................................................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
- You have written all the automation scripts in the proprietary language of a particular capture-replay tool
- 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