Difference between revisions of "TEST AUTOMATION FRAMEWORK"
Jump to navigation
Jump to search
(Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................") |
m (Topic titles in capital letters) |
||
| Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span> | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span> | ||
| − | =<span style="font-size: 16px">Pattern summary</span>= | + | =<span style="font-size: 16px">'''Pattern summary'''</span>= |
<span style="font-size: 16px">Use a test automation framework.</span> | <span style="font-size: 16px">Use a test automation framework.</span> | ||
| − | =<span style="font-size: 16px">Category</span>= | + | =<span style="font-size: 16px">'''Category'''</span>= |
<span style="font-size: 16px">Design</span> | <span style="font-size: 16px">Design</span> | ||
| − | =<span style="font-size: 16px">Context</span>= | + | =<span style="font-size: 16px">'''Context'''</span>= |
<span style="font-size: 16px">This pattern is appropriate for long lasting automation.</span><br /> <span style="font-size: 16px">If you just plan to write a few disposable scripts you will not need it.</span> | <span style="font-size: 16px">This pattern is appropriate for long lasting automation.</span><br /> <span style="font-size: 16px">If you just plan to write a few disposable scripts you will not need it.</span> | ||
| − | =<span style="font-size: 16px">Description</span>= | + | =<span style="font-size: 16px">'''Description'''</span>= |
| − | <span style="font-size: 16px">Using or building a test automation framework helps solve a number of technical problems in test automation. A framework is an implementation of at least part of a testware architecture.</span><br /> <br /> <span style="font-size: 16px"> | + | <span style="font-size: 16px">Using or building a test automation framework helps solve a number of technical problems in test automation. A framework is an implementation of at least part of a testware architecture.</span><br /> <br /> <span style="font-size: 16px">Useful tip from James Tony: Select your test framework with care – a wrong decision (like use of “make” to run tests) can take a long time to fix further down the line.</span> |
| − | =<span style="font-size: 16px">Implementation</span>= | + | =<span style="font-size: 16px">'''Implementation'''</span>= |
| − | <span style="font-size: 16px">Test automation frameworks are included in many of the newer vendor tools. If your tools don’t provide a support framework, you may have to implement one yourself. </span><br /> <br /> <span style="font-size: 16px">Actually it is often better to design your own [[TESTWARE ARCHITECTURE]], rather than adopt the tool's way of organising things - this will tie you to that particular tool, and you may want your automated tests to be run one day using a different tool or on a different device or platform. If you design your own framework, you can keep the tool-specific things to a minimum, so when (not if) you need to change tools, or when the tool itself changes, you minimise the amount of work you need to do to get your tests up and running again.</span><br /> <br /> <span style="font-size: 16px">The whole team, developers, testers, and automators, should come up with the requirements for the test automation framework, and choose by consensus. If you are comparing two frameworks (or tools) use [[ | + | <span style="font-size: 16px">Test automation frameworks are included in many of the newer vendor tools. If your tools don’t provide a support framework, you may have to implement one yourself. </span><br /> <br /> <span style="font-size: 16px">Actually it is often better to design your own [[TESTWARE ARCHITECTURE]], rather than adopt the tool's way of organising things - this will tie you to that particular tool, and you may want your automated tests to be run one day using a different tool or on a different device or platform. If you design your own framework, you can keep the tool-specific things to a minimum, so when (not if) you need to change tools, or when the tool itself changes, you minimise the amount of work you need to do to get your tests up and running again.</span><br /> <br /> <span style="font-size: 16px">The whole team, developers, testers, and automators, should come up with the requirements for the test automation framework, and choose by consensus. If you are comparing two frameworks (or tools) use [[SIDE-BY-SIDE]] to find the best fit for your situation.</span><br /> <br /> <span style="font-size: 16px">A test automation framework should offer at least some of the following features:</span><br /> |
| − | * <span style="font-size: 16px">Support [[ | + | * <span style="font-size: 16px">Support [[ABSTRACTION LEVELS]]</span> |
| − | * <span style="font-size: 16px">Support use of [[ | + | * <span style="font-size: 16px">Support use of [[DEFAULT DATA]]</span> |
* <span style="font-size: 16px">Support writing tests</span> | * <span style="font-size: 16px">Support writing tests</span> | ||
* <span style="font-size: 16px">Compile usage information</span> | * <span style="font-size: 16px">Compile usage information</span> | ||
| Line 18: | Line 18: | ||
* <span style="font-size: 16px">Report test results</span> | * <span style="font-size: 16px">Report test results</span> | ||
<br /> <span style="font-size: 16px">You will have to have [[MANAGEMENT SUPPORT ]]to get the resources you will need, especially developer time if you have to implement the framework in-house.</span><br /> | <br /> <span style="font-size: 16px">You will have to have [[MANAGEMENT SUPPORT ]]to get the resources you will need, especially developer time if you have to implement the framework in-house.</span><br /> | ||
| − | =<span style="font-size: 16px">Potential problems</span>= | + | =<span style="font-size: 16px">'''Potential problems'''</span>= |
<span style="font-size: 16px">It is not necessarily easy to acquire or make a good test automation framework, and it does take effort and time. But it is very worthwhile when done well.</span><br /> <span style="font-size: 16px">If you intend to develop a framework in-house make sure to plan for the necessary resources (developers, tools etc.) otherwise you could end up with a good framework that must be abandoned because for instance the only developer leaves the company (see issue ''[[KNOW-HOW LEAKAGE]]'' for more details).</span> | <span style="font-size: 16px">It is not necessarily easy to acquire or make a good test automation framework, and it does take effort and time. But it is very worthwhile when done well.</span><br /> <span style="font-size: 16px">If you intend to develop a framework in-house make sure to plan for the necessary resources (developers, tools etc.) otherwise you could end up with a good framework that must be abandoned because for instance the only developer leaves the company (see issue ''[[KNOW-HOW LEAKAGE]]'' for more details).</span> | ||
| − | =<span style="font-size: 16px">Issues addressed by this pattern</span>= | + | =<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= |
''<span style="font-size: 16px">[[HIGH ROI EXPECTATIONS]]</span>''<br /> ''<span style="font-size: 16px">[[INADEQUATE TOOLS]]</span>''<br /> ''<span style="font-size: 16px">[[MULTIPLE PLATFORMS]]</span>''<br /> ''<span style="font-size: 16px">[[NON-TECHNICAL-TESTERS]]</span>''<br /> ''<span style="font-size: 16px">[[STALLED AUTOMATION]]</span>'' | ''<span style="font-size: 16px">[[HIGH ROI EXPECTATIONS]]</span>''<br /> ''<span style="font-size: 16px">[[INADEQUATE TOOLS]]</span>''<br /> ''<span style="font-size: 16px">[[MULTIPLE PLATFORMS]]</span>''<br /> ''<span style="font-size: 16px">[[NON-TECHNICAL-TESTERS]]</span>''<br /> ''<span style="font-size: 16px">[[STALLED 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 /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span><br /> <span style="font-size: 14px">B2 11 13</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 /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span><br /> <span style="font-size: 14px">B2 11 13</span></div> | ||
Revision as of 13:23, 28 April 2018
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns
B2 11 13
Pattern summary
Use a test automation framework.
Category
Design
Context
This pattern is appropriate for long lasting automation.
If you just plan to write a few disposable scripts you will not need it.
Description
Using or building a test automation framework helps solve a number of technical problems in test automation. A framework is an implementation of at least part of a testware architecture.
Useful tip from James Tony: Select your test framework with care – a wrong decision (like use of “make” to run tests) can take a long time to fix further down the line.
Implementation
Test automation frameworks are included in many of the newer vendor tools. If your tools don’t provide a support framework, you may have to implement one yourself.
Actually it is often better to design your own TESTWARE ARCHITECTURE, rather than adopt the tool's way of organising things - this will tie you to that particular tool, and you may want your automated tests to be run one day using a different tool or on a different device or platform. If you design your own framework, you can keep the tool-specific things to a minimum, so when (not if) you need to change tools, or when the tool itself changes, you minimise the amount of work you need to do to get your tests up and running again.
The whole team, developers, testers, and automators, should come up with the requirements for the test automation framework, and choose by consensus. If you are comparing two frameworks (or tools) use SIDE-BY-SIDE to find the best fit for your situation.
A test automation framework should offer at least some of the following features:
- Support ABSTRACTION LEVELS
- Support use of DEFAULT DATA
- Support writing tests
- Compile usage information
- Manage running the tests, including when tests don't complete normally
- Report test results
You will have to have MANAGEMENT SUPPORT to get the resources you will need, especially developer time if you have to implement the framework in-house.
Potential problems
It is not necessarily easy to acquire or make a good test automation framework, and it does take effort and time. But it is very worthwhile when done well.
If you intend to develop a framework in-house make sure to plan for the necessary resources (developers, tools etc.) otherwise you could end up with a good framework that must be abandoned because for instance the only developer leaves the company (see issue KNOW-HOW LEAKAGE for more details).
Issues addressed by this pattern
HIGH ROI EXPECTATIONS
INADEQUATE TOOLS
MULTIPLE PLATFORMS
NON-TECHNICAL-TESTERS
STALLED 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 Design Patterns / Back to Test Automation Patterns
B2 11 13