How do I get started with test automation?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
First, you might start by asking yourself and your team several questions:
- Does the test team have the skills needed to build automation? If no, can you get funding for training?
- What tool(s) and language(s) do you have the skills and funding for?
- Is there a commitment and understanding from the team and your management on how much time, effort and resources are needed to get automation started and to keep automation running?
- Are there expectations -- stated or unstated -- by your project team, project manager and your management? It may be worth writing down the expectations and discussing those expectations as directly as possible, and as soon as possible.
- What do you want to automate? What's realistic?
- Can you get a trial version of a tool or download an open source tool with the plan to "give it a try" for a short period of time before committing more funding or time investment?
Next, although it may sound negatively-focused, I thought I would highlight some of the most repeatable failures I’ve seen in test automation over the years (this list is in no particular order).
- Lack of time when project work “heats” up and automation gets left behind.
- A key resource (automation champion) leaves the team or company.
- The automation tool and the application being tested are no longer as compatible as they were when the tool was selected.
- The extent of the start-up effort contrasted to the immediate low payback frustrates the team or management and automation is abandoned.
- Automation coverage is unrealistically optimistic in the beginning and automation begins to be seen as a failure rather than waiting out the start-up time investment.
Overall, it takes a champion, an advocate, to get automation up and running on a project, but the payoff can be worthwhile. I’ve raised some of the most frustrating and difficult aspects, but this is only meant to help highlight challenges, not to discourage you from trying.
A third step would be to start planning. Brainstorm with your team and plan a flexible framework. Think modular. Create and use naming conventions. Plan for code and function re-use. And although the book was written more than a decade ago, a book I found helpful when building automation was Software Test Automation by Mark Fewster and Dorothy Graham.
This was first published in January 2011