This guide describes the pros and cons of continuous regression testing to improve quality and reduce defects while increasing the business value of QA testing.
Regression testing amounts to a necessary evil within the software development industry. Despite the time and effort involved in developing a regression test suite and maintaining it, defects tend to persist regardless. Regression testing intends to retest the application code to ensure its stability each time new release code merges into the main code base.
The purpose of regression testing software applications is to defend the customer against new defects being introduced with new code. Let me ask you—have you been the recipient of defects after a new software release? It’s aggravating and repetitive. If you escape with simply an annoying defect that breaks your workflow, that’s considered lucky. If regression testing is executed to prevent new defects from affecting the existing application’s functionality, why does nearly every single release contain new defects?
Regression testing fails to protect customers from defects. Granted, it’s not typically a total failure. Most QA testers register numerous defects during regression testing and typically the highest priority bugs are fixed within the release, but rarely all of them.
Numerous defects are missed during regression testing largely due to differences between testing environments and the customer’s actual production environment. Defects are often introduced when reported defects are fixed. The QA testing teams does not restart the regression testing process on each code build, so defects easily slip in and go unnoticed until release.
How can QA testing teams defend customers against a constant barrage of defects in a release more effectively? Is there a cost-effective and time-sensitive method of regression testing that reduces the number of defects in a release? Is there a regression testing method that doesn’t directly impact release schedules or cause additional work—or worse, re-work? This is where continuous regression testing comes in, and it’s what we’re going to talk about today.
This guide describes the pros and cons of continuous regression testing to improve quality and reduce defects while increasing the business value of QA testing.
Continuous regression testing takes the concept of continuous development and deployment and puts it in the regression testing realm. Continuous deployment is a way for Agile and DevOps software development teams to improve software quality by releasing code changes in smaller packages more frequently.
Advantages of continuous deployment include:
Continuous regression testing simply takes a continuous cycle and uses it for regression testing. Continuous regression testing is executing regression tests on an ongoing basis rather than during a planned testing cycle. Testing occurs during development, post-development, and both pre- and post-release. Testing becomes continuous regardless of the iteration or phase of development.
Continuous regression testing requires a QA testing team and a suite of manual and/or automated regression test scripts, user documentation or a collection of user stories. When continuous regression testing is selected, the first step is planning a testing strategy.
A test strategy simply defines how the regression testing is executed, who is testing and where. For example, if a QA testing team has both automated and manual regression testing suites then start by reviewing the order tests are executed. Start with the automation and then move into executing the more complex manual test cases.
Once the team executes the tests, they mark tests as passed or failed and note any defects found during testing. Once the regression suite test execution is completed, it starts over again. Continuous regression testing executes during all phases of development regardless of the release build. Regression test execution simply repeats in a continuing, constant rhythm.
Once a test strategy exists, determine the testing technique desired. For example, many QA teams execute continuous regression using exploratory testing. Others test continuously by planning out regression testing iterations in a test management tool and constantly repeating the test script execution. When new user stories or features are completed, then the test case for that story gets added to the regression testing suite. Defects that are fixed and not already covered by an existing test case require a new test case to be added in the technique desired.
Test execution is tracked within a test management tool or manually by having testers sign up for tests within a spreadsheet. Using a test management tool simplifies the process and allows for easier reporting on pass/fail and test execution status. The advantage of a spreadsheet is one simply writes over the pre-existing entry repeatedly. It’s easier, but this method does not preserve the test execution history as a test management tool does. Test execution history offers advantages when analyzing where defects occur in the application.
Consider rotating test suites between QA testing groups or teams to keep test execution fresh. By rotating test suites, all members of the team become familiar with a larger variety of application functionality. Fresh eyes are always good for software quality.
Continuous regression testing offers several distinct advantages. First, there’s no separate test effort to plan and schedule. No need to stop development for regression testing. QA testers simply continue regression test execution between user story and new feature testing tasks.
Continuous regression finds defects throughout the development cycle regardless of the build. No more need to constantly ensure the code build is accurate for testing. Using the latest code build is the only requirement. Testing continues up to the release to production. Continuous regression testing covers testing for fixed defects, integration issues and connectivity problems on an ongoing basis. The more defects caught during continuous testing, the fewer defects released to customers.
Continuous regression testing increases the business value of the QA testing team. How? By enabling the testing team to save time planning separate test executions. Instead of wasting time planning separately scheduled testing efforts, regression testing simply continues regardless of build or release level. Testers find more defects, keep tests maintained, and increase their knowledge of the application functionality making the QA team a more valuable business asset.
Other pros of continuous regression testing include:
What are the cons of continuous regression testing? The biggest disadvantage of continuous regression testing is it never ends. There is no end to regression testing because it’s continuously occurring. QA testing teams no longer experience downtime or waiting time between testing tasks. Testing teams also enter more defects during the entire development cycle rather than during specific testing periods.
Regression testing can become tedious when constantly repeated. To keep testing fresh, change up the testing technique or re-assign functional testing responsibilities to different teams. Another way to reduce the tedium of regression testing is holding contests within the testing team. For example, most approved defects are found during continuous regression testing or even bug hunts within known areas of the application that are defect prone.
Continuous regression testing improves customer experience by reducing defects in releases. It improves QA testing skills across the team and allows for more agility and flexibility in testing. No need to squeeze regression testing into the end of a sprint or carve out a week or two dedicated to regression testing. Keep testing focused, efficient and customer-centric with continuous regression testing. QA testing team business value increases and development continues with less interruption. Improve release times and reduce defects with continuous regression.
A QA test professional with 23+ years of QA testing experience within a variety of software development teams, Amy Reichert has extensive experience in QA process development & planning, team leadership/management, and QA project management. She has worked on multiple types of software development methodologies including waterfall, agile, scrum, kanban and customized combinations. Amy enjoys continuing to improve her software testing craft by researching and writing on a variety of related topics. In her spare time, she enjoys gardening, cat management and the outdoors.