Difference between revisions of "REFACTOR THE TESTWARE"
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 [[ | + | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span><br /> |
| − | =<span style="font-size: 16px">Pattern summary</span>= | + | =<span style="font-size: 16px">'''Pattern summary'''</span>= |
<span style="font-size: 16px">Testware must be refactored regularly just as application code.</span><br /> <br /> <span style="font-size: 16px">'James Tony': Tests have technical debt too! It may be harder to measure than the technical debt of the code being tested, but cutting corners when writing tests can lead to a build-up of technical debt that can slow you down to a crawl in the future</span> | <span style="font-size: 16px">Testware must be refactored regularly just as application code.</span><br /> <br /> <span style="font-size: 16px">'James Tony': Tests have technical debt too! It may be harder to measure than the technical debt of the code being tested, but cutting corners when writing tests can lead to a build-up of technical debt that can slow you down to a crawl in the future</span> | ||
| − | =<span style="font-size: 16px">Category</span>= | + | =<span style="font-size: 16px">'''Category'''</span>= |
<span style="font-size: 16px">Process</span> | <span style="font-size: 16px">Process</span> | ||
| − | =<span style="font-size: 16px">Context</span>= | + | =<span style="font-size: 16px">'''Context'''</span>= |
<span style="font-size: 16px">Use this pattern for long lasting automation projects in order to keep maintenance costs low. For short lived solutions you will not need it </span> | <span style="font-size: 16px">Use this pattern for long lasting automation projects in order to keep maintenance costs low. For short lived solutions 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">Refactoring means that scripts and test data should be checked regularly:</span><br /> | <span style="font-size: 16px">Refactoring means that scripts and test data should be checked regularly:</span><br /> | ||
| Line 16: | Line 16: | ||
* <span style="font-size: 16px">is the technical implementation as efficient as it can be? For example, wait times, communication methods etc. See article mentioned under Experiences below.</span> | * <span style="font-size: 16px">is the technical implementation as efficient as it can be? For example, wait times, communication methods etc. See article mentioned under Experiences below.</span> | ||
| − | =<span style="font-size: 16px">Implementation</span>= | + | =<span style="font-size: 16px">'''Implementation'''</span>= |
<span style="font-size: 16px">After you have determined what should be refactored schedule when to execute the updates and control that they get done:</span><br /> | <span style="font-size: 16px">After you have determined what should be refactored schedule when to execute the updates and control that they get done:</span><br /> | ||
| Line 25: | Line 25: | ||
* <span style="font-size: 16px">Check that you are using the [[RIGHT INTERACTION LEVEL]]</span> | * <span style="font-size: 16px">Check that you are using the [[RIGHT INTERACTION LEVEL]]</span> | ||
| − | =<span style="font-size: 16px">Potential problems</span>= | + | =<span style="font-size: 16px">'''Potential problems'''</span>= |
<span style="font-size: 16px">Refactoring will often be postponed when a project is running out of time. Be careful not to build up too much technical debt</span> | <span style="font-size: 16px">Refactoring will often be postponed when a project is running out of time. Be careful not to build up too much technical debt</span> | ||
| − | =<span style="background-color: #ffffff; font-size: 16px">Issues addressed by this pattern</span>= | + | =<span style="background-color: #ffffff; font-size: 16px">'''Issues addressed by this pattern'''</span>= |
''<span style="background-color: #ffffff; font-size: 16px">[[AUTOMATION DECAY]]</span>''<br /> <span style="background-color: #ffffff; font-size: 16px">''[[DATA CREEP]]''</span><br /> ''<span style="background-color: #ffffff; font-size: 16px">[[OBSCURE TESTS]]</span>''<br /> ''<span style="background-color: #ffffff; font-size: 16px">[[ REPETITIOUS TESTS]]</span>''<br /> ''<span style="background-color: #ffffff; font-size: 16px">[[SCRIPT CREEP]]</span>'' | ''<span style="background-color: #ffffff; font-size: 16px">[[AUTOMATION DECAY]]</span>''<br /> <span style="background-color: #ffffff; font-size: 16px">''[[DATA CREEP]]''</span><br /> ''<span style="background-color: #ffffff; font-size: 16px">[[OBSCURE TESTS]]</span>''<br /> ''<span style="background-color: #ffffff; font-size: 16px">[[ REPETITIOUS TESTS]]</span>''<br /> ''<span style="background-color: #ffffff; font-size: 16px">[[SCRIPT CREEP]]</span>'' | ||
| − | =<span style="font-size: 16px">Experiences</span>= | + | =<span style="font-size: 16px">'''Experiences'''</span>= |
<span style="font-size: 16px">I recently came across an article on LinkedIn by Bhushit Joshipura, called "Efficient Running of Test Automation". He describes a serious of technical "fine-tuning" that enabled him to reduce the execution time of a set of automated tests from 4.5 hours to less than 1.5 hours. A good example of technical re-factoring. You can read it here: </span><br /> [https://www.linkedin.com/pulse/efficient-running-test-automation-bhushit-joshipura?trk=prof-post linkedin]<br /> <br /> <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></div> | <span style="font-size: 16px">I recently came across an article on LinkedIn by Bhushit Joshipura, called "Efficient Running of Test Automation". He describes a serious of technical "fine-tuning" that enabled him to reduce the execution time of a set of automated tests from 4.5 hours to less than 1.5 hours. A good example of technical re-factoring. You can read it here: </span><br /> [https://www.linkedin.com/pulse/efficient-running-test-automation-bhushit-joshipura?trk=prof-post linkedin]<br /> <br /> <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></div> | ||
Revision as of 13:43, 28 April 2018
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
linkedin
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
Pattern summary
Testware must be refactored regularly just as application code.
'James Tony': Tests have technical debt too! It may be harder to measure than the technical debt of the code being tested, but cutting corners when writing tests can lead to a build-up of technical debt that can slow you down to a crawl in the future
Category
Process
Context
Use this pattern for long lasting automation projects in order to keep maintenance costs low. For short lived solutions you will not need it
Description
Refactoring means that scripts and test data should be checked regularly:
- are the automated test cases still valid and useful? .
- can the automation scripts be improved?.
- can similar scripts be merged?
- is the data up to date?
- is the documentation up to date?
- is the technical implementation as efficient as it can be? For example, wait times, communication methods etc. See article mentioned under Experiences below.
Implementation
After you have determined what should be refactored schedule when to execute the updates and control that they get done:
- KILL THE ZOMBIES
- Improve the scripts (KEEP IT SIMPLE)
- Upgrade test data to the current release
- Remove or merge duplicate scripts so that you only have to maintain one version.
- Check that you are using the RIGHT INTERACTION LEVEL
Potential problems
Refactoring will often be postponed when a project is running out of time. Be careful not to build up too much technical debt
Issues addressed by this pattern
AUTOMATION DECAY
DATA CREEP
OBSCURE TESTS
REPETITIOUS TESTS
SCRIPT CREEP
Experiences
I recently came across an article on LinkedIn by Bhushit Joshipura, called "Efficient Running of Test Automation". He describes a serious of technical "fine-tuning" that enabled him to reduce the execution time of a set of automated tests from 4.5 hours to less than 1.5 hours. A good example of technical re-factoring. You can read it here: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