When to automate?
We’ve previously looked at what is automation testing and why we do it, so now the next question is, when to automate? The obvious answer, when talking about front end testing, is ‘as soon as the GUI (the Graphical User Interface, aka the web page) is ready’, but this isn’t necessarily true. The GUI being ready is the end of the process, when all the pieces are pulled together into a whole. We can, and should, begin automation testing (AT) earlier than this. The test planning phase should start at the beginning of the project; testers should have access to those user stories early to determine which tests are going to be advantageous, which would be merely useful, and which can be ignored – for now. As the app or website is developed, the test writers should be informed of changes and additions that will affect the way the tests are run.
But the GUI isn’t the only thing that can be automated, calls to the database can be automated in order to test various functions and views, as well as database integrity. These tests can be implemented as soon as the database is up and running. Having a test, or set of tests, running against the database (or a copy of the database) 24/7 can quickly show any issues that traditional testing may not find very quickly.
Obviously, the time to start automated testing is ‘as soon as you can’. But this will vary between projects and even teams. The key things to consider when thinking of automation testing are:
- Will this test be repeated regularly?
- Will this test case benefit from being run 24/7?
- Will the cost of writing and maintaining an automated script be outweighed by the early warnings that an automated test can deliver?
If the answer to even one of those questions is yes, then automating the test scripts should be included in the early stages of the project.
We use automated tests to perform those tests which would traditionally take a lot of man hours to complete, and which by using automation can be more reliable – removing those human errors that creep in when performing the same task over and over from the equation. A great example of this is being used on one of our biggest clients to verify that particular pages (of which there are many) are all available. There are hundreds of pages, each produced dynamically, each with their own contact page. Manually testing that these pages are available and working would take an enormous effort and a lot of time but automating this task will mean that each page is tested, errors are reported, and no page is missed. The added benefit is that once the test is written it can be run at any time, for instance when a change is made to the site, or it can be run every day. The cost benefit of this in time, efficiency and actual money is substantial.
However, AT should be applied only in situations where there is an advantage to doing so. As Bill Gates said:
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
There is no point in wasting time creating and deploying automated tests if that test will only be used once in a situation that could just as quickly be manually tested, therefore proper planning and forward thinking is required to intelligently apply AT tools.
PIC RS6808_DSCF2518-scr
Another great reason for automation is in mobile testing. Traditional testing can be pretty limiting; take a device, load the software on it, manually test the features that need testing, then repeat for another device, and another, and another. These steps can be very time consuming when an app can be run on a myriad of devices and operating system versions. Imagine trying to run these tests against Samsung, HTC, One Plus and LG devices; do you test the latest flagships only? A variety of their devices? A variety of Android versions? This can quickly run into tens or even hundreds of tests. And this is without even considering Apple OS devices. Using automation software and platforms, one test can be written then deployed across all these devices simultaneously – greatly reducing the time (and money) taken to verify the app works on the platforms it’s designed for. If an app changes a bit, then the test can be altered (if necessary) and then re-deployed across all the devices again, slipping perfectly into the regression testing process.
Automation testing can be started as soon as there is a GUI framework in place to test against. The planning phase should, of course, start a lot sooner.
At DRPG, we are following in the footsteps of giants; Google, Facebook, Amazon, and Microsoft all use automation testing as part of their QA process. These are the biggest companies in the world and whilst their success is not dependent on AT, the fact that they use it can only be an indicator of its advantages.
Automation, when used efficiently, can decrease deployment time, remove human error, cut costs, and monitor production 24/7.
Sounds good to me.
