The core components of any great business case for securing software testing tools should include 10 essential elements. The first 5 of these are:
1. Title Page
The title page is the first impression a reader gets of a business case. Make sure it is neat and orderly, simple, balanced and easy to read. It should contain as a minimum, the following:
• title of project
• project designation (number, location, etc.)
• name of the organization
• date of approval.
2. Table of Contents
The table of contents lists the major headings in the business case, and the page on which each is found. Do not forget to number the pages in the document.
The table of contents can usually be generated automatically by your word processing software: if not, then do not forget to bring it up to date once you have finished the whole document and carefully check over the headings and page numbers to ensure it is 100% correct.
3. Management Summary
This is the most important selling tool. It is where you create the critical first impression of the project so it is important to summarise the most important elements of the project in a concise, compelling manner using non-technical terms that are easy to read and easy to understand.
Guidelines for writing the executive summary are listed below.
• describe the project precisely and concisely, avoiding excess descriptive words
• avoid any technical terms, jargon and abbreviations (especially TLAs: three-letter-acronyms) that will lose the attention of your audience
• explain why the project is necessary and why it is the best solution
• outline the most important benefits of the project to the business
• outline the costs and major disadvantages, if any
• summarize the most important reasons for recommending the project
• limit to one page in length only
• write after the business case is completed
Keep the executive summary to one page or less. A busy senior manager should be able to read through the management summary and have all the critical information needed (cost, benefit, timescales) to make a decision there and then.
4. Mission Statement
This is a concise and general statement of what the team intends to achieve by completing the test automation project. It explains what is to be done, for whom, and why. If possible do not exceed one sentence.
For example: the test team will implement a test automation framework in order to reduce the time taken to regression test applications thereby increasing the consistency of our regression testing efforts and releasing testers to concentrate on more critical testing tasks.
5. Project Objectives
What, precisely, will be achieved by completing the project? State the objectives clearly – one short statement for each, without accompanying arguments or documentation. These appear in the body of the report and in the project summary. It should be clear to the reviewer how these objectives relate to the mission statement of the test automation project.
Objectives are Specific, Measurable, Achievable, Realistic and Timely (S.M.A.R.T.). These define the results expected as a direct consequence of the project’s completion. Such hard data verifies the value of the project and will justify the project in business terms to senior management.
They can include such goals as:
• increasing product release quality by
• running more regression tests
• performing tests which are impossible to run manually (e.g. load tests)
• improve the consistency and repeatability of tests
• reuse of tests over different releases and products
• improving use of resources by automating boring and menial tests
• speeding up time to market by completing tests quicker
• increasing confidence in release quality when automated tests complete successfully
• earlier identification of problems and issues
• increasing tester motivation through learning new skills
• freeing up test resources to work earlier in the software development life cycle
• removing barriers and bottle necks to release
Some test automation projects have long- and short-term objectives. Identify these as such if it adds to the understanding of the project. For example, the short-term objective may be to increase the amount of regression tests run before a release. In the long term, the objective may be to attract better quality test team staff due to the advanced status of the test environment.
Sample objectives:
• to automate 60% of regression tests by (date)
• to reduce time required to complete a full regression test by 3 days
• to execute load testing on every version of the product delivered to the test team
• to identify 30% of all high priority defects raised earlier in the test cycle
• to attract 7 new, highly qualified, testers by (date)
The discussion following each objective should clarify the analysis or rationale for arriving at the objective.
For example: Currently our full regression test suite takes 2 weeks to run. A fully automated regression test suite would take 1 day to run and 2 days to analyse the results. This will reduce our regression testing resource requirements by 7 man days. On a typical project this will increase the product release quality and reduce our time to test by 1 month.
In the next post we’ll cover the other 5 essential elements that should be included in your business case.