04 Mar Don’t Overlook Your Regression Testing
Today, we’re going to discuss regression testing, which is a topic that it is so common that people feel as though there’s not much more they can learn about it and, yet, it’s interesting because when it comes to strategic test planning, it’s an area that I find a lot of organizations have challenges with. Hopefully, you’ll learn a few tidbits in this blog.
When it comes to regression testing, IEEE, the Institute of Electrical and Electronics Engineers, defines regression testing as the selective testing of software to detect defaults introduced during modification of a system or system component to verify that modifications have not caused unintended adverse effects or to verify that a modified system or system component still meets the specified requirements. More simply, regression testing is the strategic process to retest something that has already been tested, looking for inadvertently introduced defects.
Regression testing should always be performed whenever new releases of the packaged software had been put out to production. When the application is enhanced or changes are made for any reason whether they’re support software changes and then even if either side of a system interface has changed if there are changes to the configuration, be sure to perform regression testing and whenever changes are made after a testing stage is completed.
The two primary objectives of regression testing are to ensure that what has been fixed is truly fixed. Does it work as intended? Does it meet specifications and is it now fit for use? Remember, fit for use is based on what the end user, the customer determines. The second primary reason is to ensure that no other defects have been introduced. It is very important to have a regression test suite, an RTS, which is a collection of tests.
I’d like to share some design tips for a more effective RTS. You want to make sure that you keep the test simple and independent. Group linked tests into an easily identifiable test group or test suite so that test cases are run, deleted and moved as a single unit. Utilize an intuitive name so that it’s obvious what that RTS does. Modularize test scripts to facilitate change handling and also to decrease maintenance. Lock critical test into the fundamental test suite. Those are the core that you’re always going to run.
Let me share with you what I’ve seen as the five most common problems when it comes to organizations strategically creating an RTS.
The first one and perhaps the most obvious is that they have no regression test suite, nothing exists.
The second is that the validity of existing RTS is unknown. Do you know whether or not any of the test in your RTS are obsolete? Are they still valid?
Thirdly, the original conditions in the RTS cannot be recreated.
Fourth, it’s too large to run after each change so your regression test suite is just too massive.
There are too many test cases and typically that is a sign, an indication, I’m willing to bet, that the organization does not have, and that brings us to our fifth, any regression test tools. They don’t have anything for test automation. But, remember, it is very important to regularly ask yourself: is our regression test suite still okay? Are all of our tests valid? Do any need to be modified or any obsolete? Do they still test what we need to validate and are they finding defects? Ask yourself that.
Keep your RTS up to date and, believe me, your regression testing will go so much smoother.
