7 Ways to Decide Which Test Cases to Automate

Testing is the key to shipping flawless software. Without it, you risk giving customers bad experiences, or frustrating users of your product or product features to such a degree that they stop using your software entirely. But testing can be a time-consuming, and even expensive process, requiring great detail orientation, tedious processes, and ever-changing techniques. And the expertise and energy required to do it well can keep your staff stretched thin, rather than focusing on improving products, writing new code, tech debt, documentation, and other important second-order software development tasks.

Luckily, we’re now in the age of automation -- and the golden age of testing automation. By automating many of the quality testings your team needs to run in order to ensure you’re shipping quality software, you’ll save time and money, produce better software, and ensure your dev teams are happier and less overworked.

But beware: not every test is right for every piece of software, and not every piece of software is right for testing automation. Which is why we’ve written this article. Below, we’ve outlined some of the most important types of test cases, and the best automation fit for many of them. So when it comes time to test your code, you’ll be best equipped to do it, quickly, efficiently, and effectively.

• Is it a test that often causes human error?

This may seem clear, but that doesn’t mean it isn’t important. Some tests are more complicated than others, and those that are more complicated tend to be prone to induce human error. One thing automation can reduce is…human error. Often, just because a test can confuse a human, doesn’t mean it’ll confuse a machine. So try to focus on automating these tricky tests first and foremost -- both to reduce human error, increase the reliability of your testing program, and to de-stress your busy QA team.

• Is it a test that you’ll need to run again and again?

Sometimes the greatest labor required in testing is building a test, and sometimes the greatest labor is in running it. If the test is automated, however, you only have to build it once, and then you can run it again and again without worry. That’s why when you have multiple builds that will require the same test again and again and again, you should consider automation. That way, your test-building efforts will pay dividends in time saved and QA teams kept happy.

• Is it a stress test?

Stress testing is an important part of ensuring your software can handle whatever comes into the world. It consists of putting software through much more intense conditions than you can ever expect it to endure, to ensure it can handle all the conditions it’ll likely face in the “real world.” Also, when you overwhelm your software, it can be easier to see where the cracks in the foundation are, so you can fix them quickly. Because of the intensive nature of this testing, it’s ideal automation. In fact, it’s often better, an automated test can easily create more stress than a manual tester can on their own.

• Is it a unit test?

Unit testing involves testing the absolute smallest parts of an application (the units), independently and individually, to ensure they work properly. Because such tests are done during development and are designed for code with no external dependencies (like database or web services interaction), they can be set up with automation relatively easily and with straightforward patterning.

• Is it an integration test?

After unit testing, integration testing is the second simplest form of testing and also can benefit from automation due to its straightforward nature and lack of influence on database and web services. Where unit testing tests each individual unit of an application individually and on its own, integration testing tests the interaction of these units with each other. In other words, different modules, or components of the software are tested together, as a combined (or integrated) entity.

• Is it a functional test?

The third simplest type of testing which can and should always be automated is functional testing. With functional testing, the software is tested with” black box” testing techniques -- which means techniques in which the tester does not know the internal system logic and is thus objectively able to see if the software is acting as it should in relation to the predetermined requirements of the code. Because of this objectivity and externality, functional testing can (and should often) benefit from automation.

• Should it not be automated at all?

In the world of software development, it can be easy to get obsessed with the speed and efficacy of automated testing. But sometimes it’s more efficient to just run the test (manually), then build it so that it’s automated, and then run the automation.

This is the case especially if your program or application is so early in its lifespan that it’ll likely need significant programming changes before you can even use the (built) test twice, or if you believe for other reasons the test you want to run only needs to be run that single time.

Another instance when manual testing is likely still best is when your software is so complex or functionally dynamic that it would be prohibitively difficult or time-consuming to build an automated test. Or, when what you’re testing has a significant human component, like UX, UI, interface usability, or aesthetics. At the end of the day, you have to remember what you’re testing for and why, and when testing for human experiences, it’s probably better to, well, use humans.

At the end of the day, testing automation can be something like a QA superpower: it can go a long way to ensuring your software is flawless, and your staff isn’t exhausted by trying to get it there. So explore it, implement it, and use it -- but don’t let it take over. It’s another tool for efficiency, not the answer to everything. It should never take more time than or replace the time spent on building your actual software.

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.