1. A well-defined test automation vision: This should address what and how much to automate; when to automate and how; and a prioritized test automation plan.
2. Tool(s) identified that is best suitable from cost, technology, and other points of view: Considering the rich variety of automated test tools, selecting the best suitable tool is a key decision. It’s good to maintain a reference document on capabilities of all major commercial and open source automation tools. This can help you shortlist. A few things to consider when deciding on the tools are the license cost, maintenance cost, required skills and its availability. If the best tool is not found, then some level of customization / extension might be required on an existing tool.
3. ROI that is practical: Many times the automation targets are set as percentages which may not imply anything as far as test automation is concerned. Hence, a ROI should be practical, insist where automation is the only solution, and define how cost and time benefits will be obtained wherever possible.
4. Dependencies defined, such as, impact of changes in dev plan, features. Lack of proper interfaces causes problems with work distribution. It results in code that is not maintainable, with repeat functionality, and modules that don’t interface very well.
5. Recommendations on the time-line for automation: Delayed availability of automation causes manual test passes to continue, increasing the cost of testing. If the timelines are pragmatic then such inconveniences could be reduced.
6. Appropriate features and test cases for automation selected: Test cases are sent back to test case developers for redesign or clarification because it is not clear what they do. Sometimes poorly designed test cases are automated without clarifying what they do resulting in automation that is useless. Hence, it is important to analyze the functional test coverage and propose, if applicable, additional automation test cases to improve the coverage.
7. Realistic budget for automation available: It is not practical to plan for everything with respect to automation. However, if you have done due diligence in selecting the right-set of features and test cases to be automated, and considered the points discussed above, then you are better informed and can be rest assured that your effort estimates will not be wildly out of track.
8. High level design that is scalable and allows future addition of test cases: Automation would be a waste of exercise if the effort to add new test case OR maintain the existing scripts is significantly higher. In short, it should give you the best ROI for the effort involved.
9. A plan to manage and maintain the Automation (post-delivery): A design document, user guide, and how it will be handed over to anyone else should be available. It should not need much support for future runs of the automation OR to make minor changes to the scripts.
One must note that each automation project is different and brings with it its own challenges and benefits. These are my thoughts from experience in executing several test automation engagements.