What Types of Software Testing Can and Should Be Automated?

Share on FacebookTweet about this on TwitterShare on LinkedInGoogle+

Share on FacebookTweet about this on TwitterShare on LinkedInGoogle+

Creating test automation for a software project is a must! Automation increases accuracy for monotonous tests, increases testing coverage, and can even assist with load and concurrency testing. Furthermore, adding automated tests to the software build process can prevent buggy builds from going to your testers. Automation even improves team morale by automating repetitive tasks so testers can spend more time on challenging and worthwhile tasks like exploratory testing. Like I said in an earlier blog, automation can never fully replace manual testing. Instead, automation’s most basic function is to actually determine if the code is operational.



There are so many different kinds of testing that I cannot begin to define each and every type in this blog. Instead, I will focus on the types of testing that can be automated and how much each type makes up your total automation library. These types of tests are Unit Tests, Integration Tests, and GUI Tests. For a definition of Unit Tests and Integration Tests, see LaTonya Pearson’s blog The Four Levels of Software Testing. GUI Tests focus on the Graphical User Interface, which represents how you interact with the interface through graphical icons and other visual indicators.

What Types of Testing Can Be Automated?

Unit Tests: The largest portion of your automation tests consist of your Unit Tests. Unit Tests are tests that are fast, reliable, and only test tiny bits of code logic. Since automated Unit Tests are quick to develop and can be easily incorporated into your Continuous Integration process, these tests comprise the largest portion of your automated tests. I would encourage your software developers to create lots of Unit Tests and to perform test-driven development with all new software code.

Integration Tests: Next, have your testers create automated Integration Tests for all areas that cannot be Unit Tested. These tests are much more difficult to write, run more slowly, and require a lot of coding. Given the tremendous resources required, it’s critical to prioritize which Integration Tests to automate using a prioritized automation backlog. At the very least, create an automated Smoke Test to add to your Continuous Integration process. A Smoke Test is a high-level, preliminary test to reveal simple failures severe enough to reject a prospective software release.

To determine other Integration Tests to automate, start an automation backlog. Then, prioritize your backlog items. First, assess the monetary value and focus on the highest return items. Next, look at high usage areas of your software and then determine what browsers need to be tested. Note the top couple of browsers, but focus on the top browser for now. This is the browser you will start using for automation. Lastly, review your bug list for risky areas of the software that tend to break frequently. Compare this to your backlog. If an issue has happened numerous times and has the potential to occur again, move that backlog item up in priority. If issues keep cropping up that are related to a specific browser, move that browser up in the backlog as well. Once an automated Integration Test is stable, add this automation to your Continuous Integration process.

GUI Tests: The Graphical User Interface (GUI) also needs to be automated in order to exercise all the functionality and paths of the application. GUI automation is tricky because it’s usually comprised of numerous dependencies. For example, some functionality of the system may only be accomplished by following a complex sequence of GUI events. Since the GUI may change significantly across versions of the application, GUI tests can frequently break, so this portion of automation should make up the smallest percentage of your automated tests.

At Segue, I focus on creating automation scripts for Integration and GUI tests, mostly focused on web applications. On rapid-pace projects and particularly for mobile applications, usually the only automation is done with Appthwack’s UI/Application Monkey Exerciser. The Monkey is a program that runs on an emulators or real devices performing random clicks, touches, gestures, and system level events. The Monkey requires virtually no investment in terms of setup and can be easily used on as many devices as desired.

Download our Quality Control eBook