3 examples of when to use automated testing
by Jonathan Englund ✦ 19 October 2022 ✦ 5 Min Read
Beyond bringing websites and shiny new apps to life, one of the key responsibilities of a software developer is testing. We don’t mean physically running through every step of every possible user journey. We mean writing automated tests that continually check that the isolated code (units), external dependencies (integrations), and complete flows (end-to-end) are all firing correctly.
How much time a developer spends writing automated tests can vary greatly depending on the project. And whilst it may seem beneficial to enforce a very high or even 100% test coverage on a digital product, if you’re chasing a number, you’ll end up wasting time and money on writing useless tests.
However, certain scenarios can really benefit from built-in testing. Here are a few we’d recommend.
1. If the code is business critical
As a user, it’s always frustrating when a website or app does not behave as you need or expect. Especially when you’re following the journey dictated by that digital product. But the level of frustration and knock-on effect for the business can change depending on the journey. I’ll give you an example.
Your basket is full, and you’ve entered your card details, but for some reason, you’re unable to complete your purchase. In this circumstance, most people will abandon their cart and go elsewhere. Not only has the user had a bad experience, but the business has just lost a sale, which automated testing may have prevented or at least flagged early enough to prevent bigger losses.
2. If the code is used in multiple places
In an ideal world, your digital product would be a seamless composition of many reusable units of code or functions. Because code that can be referred to or pulled into multiple areas of your product is a big win in terms of efficiency and cleanliness. But shared code also has a bigger impact on product reliability.
Say, you’ve decided to grow your team of devs to help scale your digital product. It may not be obvious that a piece of existing code has been referred to in multiple places. So, if a dev changes that piece of code to solve a problem in one area of the product, that change can “break” critical flows elsewhere.
In short, if you’re using code in multiple places, the stakes will be higher, so it’s worth taking care of that code with a unit test.
3. If the code is complicated
Like most things, there are varying levels of complexity within the world of coding. Some of the more complicated functions include those with nesting (when a piece of code that performs a particular function is contained within code that performs a broader function) and those that come with a lot of different options and onward journeys.
In both cases, having automated tests in play will improve overall confidence in the product’s integrity. It will also assist with the ongoing quality assurance burden, saving both time and money down the line. It’s also worth noting that more complicated code can often be found in the features and functionality intrinsic to the core value of a product, which makes it doubly important to test.
Ready to implement automated testing?
Ultimately, automated tests exist to improve the overall reliability of a digital product. But if you’re tight on time, budget or resource, you should avoid writing tests that won’t shift the needle.
Instead, write tests to cover business-critical functions, features and functionality that speak to the product’s core value and code used in multiple places.
Although these tests will cost you time and money, you’ll more than make it back by clocking issues before they escalate. And remember, if you don’t do the testing, your users will.
