View source for TEST AUTOMATION BUSINESS CASE

<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Patterns]] / Back to [[ Test Automation Patterns]]</span><br /> 
=<span style="font-size: 16px">Pattern summary</span>=
<span style="font-size: 16px">Present a business case as for any other project, but provide also factors typical for test automation</span>
=<span style="font-size: 16px">Category</span>=
<span style="font-size: 16px">Management</span>
=<span style="font-size: 16px">Context</span>=
<span style="font-size: 16px">You will need to apply this pattern if you have to convince management to support your test automation project.</span><br /> <span style="font-size: 16px">It will not be necessary if you are only developing disposable scripts or if you already have good management support for automation without needing to make a business case. For example automation may be the only way to survive in agile development in a fast-moving industry.</span>
=<span style="font-size: 16px">Description</span>=
<span style="font-size: 16px">You present a business case as for any other project, but you should also provide factors typical for test automation, like the quality improvement due to broader testing or the reallocation of tester capacity to more challenging tasks once test automation has been implemented. These factors should be directly related to your own goals for automation.</span>
=<span style="font-size: 16px">Implementation</span>=
<span style="font-size: 16px">In order to succeed in test automation, you must first [[SET CLEAR GOALS]]: what do you want to achieve with the project? What not? It is crucial that you make very clear what test automation can or cannot deliver. This is important for everyone, but is particularly important when you make a business case for automation - if you set unachievable goals, you are guaranteed to fail!</span><br /> <br /> <span style="font-size: 16px">The essence of a business case is to show that the benefits of the proposed course of action will be greater than its cost. The equation used for this is Return on Investment (ROI) = (benefit - cost) / cost. This gives a number (often quoted as a percentage). If the benefit is worth double the cost, then the ROI is 1 (or 100%). </span><br /> <br /> <span style="font-size: 16px">In order to compare manual testing to automated testing, first determine the costs of the manual testing process that you intend to replace with automation. Factor in the number of times the tests will (or should) be run. A given set of manual tests generally costs twice as much to run them 2 times, etc.</span><br /> <br /> <span style="font-size: 16px">Then, estimate the planned costs for automation, including: </span><br /> 

* <span style="font-size: 16px">Time and resources needed to select a suitable test tool</span>
* <span style="font-size: 16px">Tool licences and maintenance costs</span>
* <span style="font-size: 16px">Training</span>
* <span style="font-size: 16px">Learning times</span>
* <span style="font-size: 16px">Time and resources to develop the [[TESTWARE ARCHITECTURE]]</span>
* <span style="font-size: 16px">Time and resources to develop the test automation infrastructure</span>
* <span style="font-size: 16px">Maintenance costs for a test automation infrastructure</span>
* <span style="font-size: 16px">Time to build new automated tests</span>
* <span style="font-size: 16px">Maintenance costs for test automation testware</span>
* <span style="font-size: 16px">Time needed for refactoring the automation testware over time</span>
* <span style="font-size: 16px">Time to analyse failures found by the automated tests (this may be significantly greater than in manual testing)</span>
<br /> <span style="font-size: 16px">Now comes the more difficult part - estimating the benefits of automation, the return that could be expected on the investment. In order to use the ROI equation, the benefits need to be converted into the same units as the costs, usually money! Here are some ideas:</span><br /> 

* <span style="font-size: 16px">Saved tester time = Time needed by the human tester to run a set of tests manually, minus the time needed for those same tests once they are automated. This is relatively easy to estimate using a "loaded salary cost" for the human testers.</span>
* <span style="font-size: 16px">Number of automated test runs necessary for pay off - this can be calculated by the savings in human time multiplied by the number of times the tests would be run (or number of releases). When the savings catch up to the investment, then you are "in credit" and have a positive ROI.</span>
<br /> <span style="font-size: 16px">But this is not the whole story. Other factors may not be easily converted into money to put into an ROI calculation, but are an important part of a business case.</span><br /> 

* <span style="font-size: 16px">The automation can free the testers from mundane and repetitive activities to concentrate on devising more and better tests.</span>
* <span style="font-size: 16px">More tests can be run more often, so more of the software can be tested in each build or release. This increased coverage can give greater confidence that the system will work well.</span>
* <span style="font-size: 16px">Improved morale of the testers, since the tools do the tedious bits and they can use their talents more fully to do better testing.</span>
<br /> <span style="font-size: 16px">Don’t forget to [[ PLAN SUPPORT ACTIVITIES]]</span>
=<span style="font-size: 16px">Potential problems</span>=
<span style="font-size: 16px">The factors that may be easiest to put into a business case may not be all of the important factors, and may create a bias towards those factors. For example, it is easy to quantify that tester's time will be greatly reduced when tests are automated, compared to the time doing manual test execution. If this is the only factor taken into account, it may give the impression to managers that they won't need to have the testers any more! However, there are many other things that the testers need to do and there are activities that may take longer with automated tests than they did when tests were manual. Test automation should support testers, not replace them! A tool can never replace the human brain!</span>
=<span style="font-size: 16px">Issues addressed by this pattern</span>=
''<span style="font-size: 16px">[[AD-HOC AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[INADEQUATE SUPPORT]]</span>''
=<span style="font-size: 16px">Note: Freebie</span>=
<span style="font-size: 16px">If you need to calculate ROI, there is a free simple ROI calculation spreadsheet that Dot will email to you on request. Email her at info or from the contact form on her web site DorothyGraham.co.uk.</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 [[Management Patterns]] / Back to [[Test Automation Patterns]]</span></div>