So today, we’re going to talk about how test automation benefits not just your developers but also your business.
How do we define automated testing?
For this article’s purposes, the idea is not to write a few unit tests and run them sometimes. Instead, we’re talking about conducting automated testing as a part of your CI/CD pipeline. Your goal should be to integrate tests into every part of your deployment process. This means that you’ll want to conduct a variety of tests. Again: the goal isn’t just to write a few unit tests and call it a day. Truly reaping the benefits of automated testing means making testing a core part of your software team’s culture.
1: You’ll ship more often
This might not be the most obvious benefit for your team. (We’ll get to some of those more obvious benefits later on.) But this is the biggest benefit. The folks behind the book Accelerate studied a number of software businesses. I don’t want to spoil the whole book, but they found conclusively that teams that ship more often see real benefits to their business. Nicole Forsgren, author of the book, drove it home when she wrote, “We found that where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.” The absolute best way to make code deployments less painful is to surround your software with high-quality tests and run them before every deployment.
So how does automated testing mean that you ship more often? Automated testing means you validate that both existing code and new features work every time your team commits. When you fully adopt automated testing as a part of your team’s culture, you know that you’re safe to ship code as soon as your pipeline goes green. Instead of waiting for a manual QA process or guessing that your code is good to go, you know that it’s good to go.
2: You’ll understand your code better
Alright, let’s cover one of the more obvious benefits of automated testing. It’s pretty straightforward: you’ll understand your code better. Software tests are the best form of documentation, because automated tests must pass every time. So when you’re trying to understand what a block of code does, you can go look up the tests for that code. Those tests outline how the code behaves. If the tests are high-quality, you’ll also have a good map of an entire class or function.
Comprehensively testing your code changes how you think about code
3: You’ll write better code
Comprehensively testing your code changes how you think about code. You design your code to be smaller, simpler, and more accessible. Why? Because it’s easier to write tests. Thirty years ago, it was considered “good design” to code objects which encapsulated lots of internal private logic. Changing the logic within one of those classes is often challenging. Because the class contains many internal code paths, validating that your change doesn’t break anything is difficult.
Embracing automated testing throws all of that design out the window. Writing automated tests for complicated objects is difficult, so you stop writing complicated objects. Instead, you write simple, straightforward functions. Those simple functions and tests mean that when you need to change your code, you validate those changes rapidly. Safely making changes enables your team to experiment more often and adapt your code to what you need it to do.
4: Debugging is faster
Just about every experienced engineer has a horror story of a major production bug that they had no clue how to fix. The story probably involves either figuratively or literally bashing their head against a keyboard during a protracted debugging session. When you have automated tests, you don’t have to relive this kind of story. Instead, you’re able to encapsulate nasty bugs in an automated test and run that test in a development environment. From there, attaching a debugger to your code is straightforward. As a bonus, when you fix the bug, you have an easy test that ensures that future changes don’t reintroduce regressions of this bug.
5: You don’t remake the same mistake
We hinted at this in #4, but it’s worth calling out as a specific benefit. Automated testing provides you the opportunity to write tests that confirm that you’ve fixed a bug. Then, those tests stay in your code base forever. Since you’re running those tests before deploying, you know that the bug won’t come back when you deploy your next set of changes.
6: You test in many more environments
If you write embedded software for one kind of smart light bulb, you’re only worried about testing on one platform. If you write a mobile app, you’ll probably test on as many platforms as you can. Whatever your circumstance, using comprehensive automated tests means that you’re able to run those tests on as many platforms as you need. It’s as simple as pushing your code onto the appropriate platform and validating that all your tests run successfully.
7: You enhance the quality of manual testing
Just because you adopt automated testing doesn’t mean that you need to fully eliminate your manual testing processes. Instead, you can focus them on the types of tests that automated tests struggle to cover. Your manual testers can work on things like ensuring that your complex business logic works like you need it to. They can save their brains for difficult questions, instead of testing things like whether email input boxes correctly handle odd inputs.
8: Your software scales better
To be clear, this isn’t magic. Writing tests doesn’t suddenly make your CPUs faster. But if you want to test how your software will work with a million people trying to use it at the same time, you can’t afford to hire that many manual testers. Well, you probably can’t, anyway. But automated testing benefits your team by unlocking those kinds of massive tests. These tests aren’t the kind of tests that you’ll want to run for every deploy. That’s probably still too expensive. But they are the kinds of tests you’ll want to run regularly, to validate how well your application scales with large numbers of concurrent users.
We don´t want to operate our software teams purely on feelings, but how your team feels about your software is still very important
9: Your developers will be happier
We mentioned this at the start, but it bears repeating. We don’t want to operate our software teams purely on feelings, but how your team feels about your software is very important. Happier developers collaborate more effectively and write better code. They have more confidence in the changes they ship. They know their code scales. Every time they ship a change, they know it won’t introduce regressions. There are no marathon debugging sessions.
Happier, more productive developers ship better features. Better features mean happier customers, and happier customers mean better business for you. If you’re thinking about embracing test automation for your software teams, the list of benefits for your organization becomes much longer than what we’ve covered here. If you’re interested in those benefits but don’t know where to start, Tricentis is more than happy to help you kick off your journey.
This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.