WavebreakmediaMicro - Fotolia
Automation. The word leads us to think of efficiency, return on investment, ways to cut expenses and methods to bring high-quality products to market faster. The test automation process sells itself to a buyer due to the word's connotation, as just described.
However, when "automation" is used in regard to software testing, it needs to be taken a little differently. Knowing when to automate testing is a very strategic process and needs to be managed by an experienced testing team.
In business, where results are expected yesterday, upper management is quick to point blame at the software testing team when a project is behind schedule. Comments like these are heard in daily status meetings: 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. Is test automation what is needed in situations like these? Or, is more thorough planning, less wasted time, and more knowledgeable resources what is truly needed?
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 does not make any friends in management when he must tell them automation cannot be done when they want it done.
Automation can be quite valuable if planned in advance and implemented correctly; but automating a test process will create value only for a functionality that requires minimal change. This includes the functions of a software application that has completed the development lifecycle, have 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 will need to 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 works. 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 functionality of the application been accepted and fully signed off on?
- Has the test automation tool been fully understood, and is it capable of being used successfully for test automation? Has a proof of concept test been done?
- Is there a development plan in place, to understand when development will be completed and when automation can begin?
- Who will be writing 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?
- Is there a maintenance plan for how after-testing is to be completed, 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