I think we can all agree that testing our development work is a requirement. What about testing the work that is related, but not being worked on? I would say we always want to test the entirety of any application we are developing and make sure everything is still functional when we’re done. Is testing your work always required? What about testing something that should never have issues because it is features that are complete (even if it is inside of an application that is being developed) and will never have any development changes? The short answer to these questions should always be “Yes.” How much testing do we need? Now that is another talk. There are also other points of discussion that will not be covered in this blog like what tools to use, or when should I use automation? For now, let’s talk about why the need for automation.
When adding a feature on top of what was already built and tested, we should then test all of our initial tests to make sure that they are still functional. Then we should test any new test that is a part of the changes. Repeating those initial tests will take time that none of us have. Time costs money, and customers don’t always see or understand the benefits of spending extra time on this side of your work. However, they do know that it should not take long to add a small addition to an already existing feature. This may be true if you’re using automated testing, but in fact, this is the exact opposite if you are not using automated testing.
Time is Money
Since time is almost always related to money, let’s start with that point. Starting on a new project should include testing. I want to say it should consist of automated and manual testing. When building the project, you will need to test manually, to make sure all features work. Then you can also create automated tests to replicate the tests you had just run, so you never need to run that specific test again manually. Doing this will take time. Some companies may even skip building automation to save time and money, but does this save time? Well, let’s take a look. Say we spent 8 hours developing a new application:
- 8 hours in feature Development
- Then we spent another 4 hours testing the application
- Then we spent another 4 hours developing automation tests that cover all of the manual tests
After 16 long hours of development, our work is complete. Now the customer requests we build another feature that extends/expands on this previous feature. Keeping it simple, we say it takes 8 more hours of development time to build the requested expansion.
- 8 Hours in feature Development
- Then we spend another 2 hours testing the application assuming you ran your previous automation tests to cover the old tests (6 hours manually assuming you had to retest everything because you’re not using automation)
- Then we spend another 2 hours developing automation tests that cover all of the new manual tests we did
If you read inside the parentheses, you’ll notice that the new feature development’s testing was reduced because of the automated testing. Overall, after the features were implemented, we now have a total of 6 hours of manual testing automated. Any new features added around this area will now be backed up by these tests to prove they still function, saving 6 hours of your time.
As you can see, the testing work seems to grow when you’re not using automated tests. However, building automated tests uses more implementation time in the beginning. Over time and continuous development, it usually works out where automation testing saves time. But this isn’t the only side with the decision of using automated testing.
How often does your development team test through an entire application to make sure the release of the application is stable? Wouldn’t you like to have the peace of mind knowing that “Section A” works when you only developed in “Section B”? Implementation with automated testing can help save a release from being a big headache. “It should work because no one coded in Section A” is something many of us have said before. Having automated tests for testing out these sections makes sense. I know I don’t want to spend money testing sections that should not have been touched. A simple “Start Test Button” and continue with my day sounds nice. It allows that level of satisfaction to know that the tests still work while we continue to develop.
Changing Functionality
Another side to think about is changing the functionality of already completed work. Changing the application’s architecture can and should change how these tests are working can cause more work to be done with testing. When doing these tests manually, you will need to go hunt down the tests that need to run (from saved documentation I hope) and then go through them again. This stage can be a hard idea to get past because you will now have to update all those tests to follow the new guidelines which you never had to worry about before (unless they were being documented. Then you need to update the document with the changed tests just as though you are updating the automated tests.). This leaves you with more work no matter how you look at it.
If you have already started using automated testing, you know a lot about what I have already spoken of, and I hope you enjoyed the read and my view on automated testing. If you have not already begun using automated testing, there are guides out there for free that can help you get started which I will share a few at the bottom. Even though the startup time to get going and as well, may take some getting use to and implement. It will be worth it in the end for the majority of projects you work on.
10-STEP AUTOMATION TESTING PROCESS: HOW TO START AUTOMATION TESTING IN YOUR ORG
https://www.softwaretestinghelp.com/automation-testing-tutorial-3/
API TEST AUTOMATION TUTORIAL: A STEP-BY-STEP GUIDE
https://www.qasymphony.com/blog/automated-api-testing-tutorial/
BEGINNER’S GUIDE TO UNIT TESTING
https://www.codementor.io/wbsimms/unit-testing-foundations-programming-beginners-du107q81d