WavebreakmediaMicro - Fotolia
The word automation leads us to think of efficiency, return on investment, ways to cut expenses and methods to bring high-quality products to market faster. That's how the test automation process sells itself to a buyer.
However, "automation" used in regard to software testing must be taken a little differently. Knowing when to automate testing is a very strategic process, and must be managed by an experienced testing team.
In business results are expected yesterday, and upper management is quick to point blame at the software testing team when a project is behind schedule. Why isn't this software/process automated? If it were automated, testing would go much more quickly. We must automate it as soon as possible.
If only it were so simple. Before invoking test automation, what's really needed in situations like these is more thorough planning, less wasted time, and more knowledgeable resources?
I've learned that last-minute calls for automation are akin to a Hail Mary play in football. Most of the resources and time for the project have already been exhausted and management is looking for a quick fix to get it back on schedule. By the time the project rolls around to the software testing team, it is already so far behind -- usually due to glitches in development and business requirements -- that no amount of automation can make up the time lost. In addition, there is a lack of understanding within upper management about how test automation works and the preparation required to set it up. To be sure, the software test manager makes no friends in management when he must tell them automation cannot be done when they want it done.
Automation is valuable if planned in advance and implemented correctly, but automating a test process creates value only for a functionality that requires minimal change. This includes the functions of a software application that has completed the development lifecycle, has been fully tested, and the results of which have been approved by the organization's subject matter experts. However, if these areas require any coding change, then automation must be reapplied.
As software test engineers, we must educate our managers -- and in some cases, our own peers -- about when to automate testing and how it should work. Here is a quick list of considerations about when to automate testing that you can present to management when a project begins, to ensure that everyone knows what to expect:
- Is the development code stable?
- Has the project team accepted the functionality of the application and fully signed off on it?
- Does the team fully understand the test automation tool, and judged its capability to be used successfully for test automation? Has the team completed a proof of concept test and what were the results?
- What is the development plan in place, to understand when development will be completed and when automation can begin? Beware inflexible deadlines, which can lead teams to take shortcuts or build poorly constructed automated tests.
- Who will write the automation scripts? If the testers who execute the manual tests are the same testers who create automation tests, will this negate the productivity of utilizing these resources?
- What is the maintenance plan for how to complete after-testing to focus on automation areas?
- How well does the project team know the software vendor, and the software testing industry?
Automated software testing basics
Manual versus automated software testing