When developing software, it is commonplace for developers to release builds and patches that introduce bug fixes or additional functionality. Sometimes the changes introduced to the software can cause existing functions to break or regress. In an effort to maintain preceding functionality, quality assurance teams often conduct regression testing. These tests are aimed at going through any and all past functionality that could be affected by new changes to the codebase.
Manual Regression Testing
In many cases, regression testing is best handled through the use of automated testing because of the tedious and simple nature of the testing. But when it comes to regression testing, there are times when test automation is less efficient than manual testing. Sometimes, it does not make sense to use automated testing unless you are going to be working on the project for an extended amount of time. It can take a decent amount of time to create automated tests, and if you are only working on a project for 1-2 months, that time can be spent more efficiently by executing test cases manually.
In its most basic form, a test case is just a set of steps that can be executed in order to reproduce the intended functionality of a feature within the software. Once a tester is familiar with the features and functionality, they can create test cases to be used when regression testing becomes necessary. The best time to write test cases for manual regression testing is when the software is still in the early stages of development. Once the functionality of the program has been set in stone, the documentation can be used as a source for the test cases. Instead of looking at an early, unfinished version of the software, use clearly defined documentation of the end-goal functionality to avoid the creation of flawed test cases.
Simple and Efficient Test Cases
Another thing to remember when creating test cases for manual execution is to make them as simple and efficient as possible. Although regression testing is important, it’s not something you’ll want to spend all of your time on. It’s very important to have test cases stick to the happy path of the software. It would be inefficient to create a test case for user interaction that strays too far from the intended use of the program. When regression testing by manually executing test cases, it’s easy to get in the state of mind that all you have to do is follow the steps in the test case. But just because there isn’t a test case for it or it is not particularly specified in the test case, does not mean that the tester can’t do a little functional testing on the side while regression testing.
While regression testing manually, testers can go beyond the steps of the test case and test the secondary interactions that aren’t in the happy path. This mix of functional and regression testing can help the tester to combat the repetition and tedium that is often associated with following written steps in test cases. It also covers more of the functionality than when just strictly sticking to regression testing and test cases. That being said, it’s important to remain focused while implementing this strategy. Deviating too far or too often from the regression tests can lead to the tester getting way off track and abandoning the test cases entirely. Keep in mind that the end-goal is to execute all of the test cases and complete the regression testing for the build.
If you have any questions about this blog post, feel free to leave a comment below.
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at firstname.lastname@example.org. You can also connect with us on Twitter, Facebook, or LinkedIn.