Test automation is a hot topic in the testing community, and a perennial topic of debate. What doesn't seem to receive the same attention, though, is task automation: automating the repetitive, non-testing processes that testers have to waste their time on.
Test automation is a hot topic in the testing community, and a perennial topic of debate. What doesn't seem to receive the same attention, though, is task automation : automating the repetitive, non-testing processes that testers have to waste their time on.
One good process to look at with automation in mind is that of deploying your software for testing. Our build processes usually generate something like an installer package, or a code branch that can be deployed to a webserver. However, as a tester, you need your product in a form that's immediately usable by an end-user and testable by you. For desktop software, this is your installer, already installed onto an OS of your choosing. For web-based software, this is a complete, working webserver that's running your application. The steps between the end of the build process and the software being ready to test are what you want to automate.
Virtualization and configuration management tools let us not only stand up and configure new machines quickly but also deploy our software onto them with a minimum of intervention. Ideally, by issuing a single command, you should be able to:
- Create a new virtual machine running your target OS
- Install your software's prerequisites, if any
- Install the build of your software you specify
- Configure it as needed for testing
Admittedly, an initial investment of time is needed to write the scripts that make all of this happen. However, it's been my experience that this pays off not only in saving the test team's time, but also in giving them much more flexibility to test different builds of the product simultaneously.
Nowadays, we have several good virtualization tools, a number of good configuration management tools, and workstations capable of running a handful of installations of our software with ease. If you need a new working instance of your application to test or experiment with, we should be well past the time when you had to spend hours building out a test machine or, worse, requesting one from your already-overworked sysadmin team.
It's accepted wisdom in the agile community that you should try to keep your build times as short as possible— ten minutes is often mentioned as a target. If waiting for hours on a build isn't agile when it comes to software development, surely pushing buttons and pulling levers for hours to set up a test instance isn't agile testing.