Tame the automation demon

Test automation is an essential requirement in any software development team. For teams that do not follow test driven development or unit testing practices, the focus of automation is to automate tests related to the UI interfaces. There are good reasons for this. All the issues encountered by the end users of the application are high priority and gets escalated quickly. The end users of the application are the ones who are expected to fuel the growth of the company by increasing their productivity by using the software developed by the company. So, any issues encountered by these end users have a direct impact on the top and bottom line of the company.

In order to mitigate these end user issues, software development teams focus on automating the functional tests through the user interfaces that are used by the end users. However, this leads to another problem. As the number of GUI tests increase, the time taken to execute the tests becomes longer and so does the time needed to maintain them. GUI based test automation is relatively fragile and it needs constant upkeep. These issues combined create a situation where the testing phase becomes exceptionally long and expensive.

One of the ways to handle this is to identify if the functional tests can be executed using APIs. Most enterprise software expose all of their GUI functions through APIs as well. If APIs are available, then we should automate all the functional tests using APIs. This will make the test execution many times faster than executing GUI based tests. In addition, the API based tests are more robust and required less up keep therefore bringing the overall cost of automation down.

Hmm… all that is good, but now how do we fulfil the need to automate the GUI tests so that we can ensure that the GUI is all good? One possible way is to create GUI based automation for some scenarios of the functional tests and create API based test automation for the rest of the scenario. Then vary the quantity of GUI and API based automation until you achieve a balance that is suitable for your situation.

Example 1: Say you have hundreds of automated regression tests based on GUI automation. You can keep the Sanity tests based on GUI automation and convert the remaining regression tests to be based on API automation. This way you will cover the most important features and use cases using GUI automation and cover the remaining in-depth tests using the API.

Example 2: Another way to look at it is, say you have an order entry page for which you have 10 test scenarios which are automated using GUI based automation. Identify 1-2 test scenarios that cover all the GUI elements in the order entry page and keep them as GUI automation. Convert the remaining 8-9 test scenarios to API based test automation. This will increase the speed of regression test execution and also reduce the time taken to add new tests.