How regression tests can save you time and money – Part 2
By Alexandra Martinez
In my previous post, How regression tests can save you time and money – Part 1, we talked about how regression testing can save you time, featuring a real-life scenario where we went from spending 50% of our time on manual testing to less than 5% with automated regression tests!
For this post, I’ll break down how implementing automated testing will also save you money.
Based on the time savings breakdown we covered in the last post, if you have a manual tester spending 1-3 days on every change to your development functionality, that’s not just adding time to the project, but also money in paying for their time to work through the testing.
When I talk about investing in automated testing, I mean that you need people that have experience implementing automated testing. You don’t necessarily need experienced manual testers, because you can just explain to them what they need to be testing. Whereas in order to create automated tests of any kind, you need to have an experienced developer that also knows the stack of technologies needed to complete these tests. Some people call them Software Development Engineers in Test, or SDETs.
“So is this going to cost me more money then?” Stick around, I’m getting there!
SDETs are popular because they not only act as testers, they’re also developers. The nature of creating automated tests is essentially programming tests to be run by a computer, which means they need basic development skills to achieve this. This means they’re not only specialized in creating the tests, but they can also act as regular developers.
It’s important to note that investing in automated testing offers an exponential return on investment, while traditional manual testing scales in a linear fashion as increasing the number of tests run means you need to hire more testers. When you invest the time and money up front into automated testing, you receive the repeatable test suite which means you can use those resources to create additional automated tests, saving time (and therefore money) on both current and future projects. These tests will not only increase other development cycles but also augment the stability of your integration projects.
Manual testing vs. automated SDET testing
Imagine you have one developer and one manual tester working on your mobile application. The developer would be working on a fix and the tester would be idle until the developer is done with the fix. When they are, the tester would review the change and the developer would now be either idle or working on more fixes. If the tester rejects the developer’s fix, the developer would have to hold off their current work and re-work on that previous functionality, and the tester would be idle again. Do you see what I’m getting at?
Now let’s use the same scenario, but with an SDET instead of a manual tester. The developer works on the fix, while the SDET creates the automated tests for it, then the fix is sent to the SDET to test, and if it’s rejected, the developer continues working on the fix. Is the SDET idle now that the tests are done? Nope, the SDET can start working on more tests, or can even start working on development fixes.
Here are some diagrams on how these two scenarios would go:
First using a manual tester:
Note that the manual tester relies on the developer to generate the code fix. If there’s no code fix, the manual tester can’t start the review process.
Now using an SDET for automated testing:
Note that here the SDET doesn’t rely on the developer to start creating the automated tests. Both the developer and the SDET can start working on the same ticket in parallel, and once the SDET is done with the automated tests, they can get assigned to another feature or bug, even if there’s no developer available yet. And as I mentioned earlier, an SDET can also perform as a developer to help create required code fixes.
Hopefully this blog series has shown you how you can save both time and money by implementing automated regression tests in your software development projects. It’s an investment but trust me, once you’ve got everything set up and in place, your project bugs will start dropping because your quality will rise, which means you’ll have less frustrated customers. Your project will also have more time to implement important features or enhancements, instead of spending time on fixing issues that were introduced by accident. Happy testing!
About the author
Alexandra is a MuleSoft Developer where she’s responsible for leading and mentoring teams, always ensuring the best quality for project deliveries. Made in Mexico, she enjoys learning new technologies and is always looking for new challenges. She loves statistics because she’s bad at them, so they keep her alive (an eternal challenge). Her natural habitat, however, involves watching Netflix and playing video games.
