TEST ENVIRONMENTSRegression Testing: How to Get it Done Better, Faster

Avatar Guest ContributorAugust 13, 20183 min

The ‘Old & Reliable’ Regression Testing

For generations of developers and testers, regression testing has served as a mainstay of quality control through its process of re-running testing scenarios against code that has been modified or tweaked in the days or weeks since the creation of the original script. But testing and retesting in this manner is tedious and costly, with some teams choosing to only test a representative set of functions or opting to look for the types of errors they know might be there, rather than searching for hidden, undiscovered problems.

Even when test automation is applied, the temptation is to automate only the tests that are not expected to break: those in the regression testing suite.

The Value of Regression Testing in the SDLC

A team starts to progress the moment it assigns testing to the entire software development lifecycle. This means not only doing automated test execution of regression testing scripts for any one particular sprint, but also automatically generating test automation scripts for the new features being coded in that same sprint.

To further this progress, teams benefit from converting old regression testing suites, containing hundreds or thousands of manual test cases, and optimizing them to ensure that only valid tests get to go forward with zero maintenance on them as the application changes. This can be done by maintaining the model that regenerates all those optimized test cases whenever there are application changes and storing them in the current test case management tool.

Improving Regression Testing Cycles

Technology like CA Agile Requirements Designer can help improve the regression testing process. Automatic requirements modeling accelerates model creation, which consequently helps generate initial flow. This is accomplished by capturing a user’s actions during a regular regression testing cycle, and then parsing this into a flowchart. The flowchart then deduplicates the steps, turning them back into one concise model. This radically simplifies and accelerates the creation of the initial models, removing the need to create them by hand.

Stephen Tyler, VP Software Engineering at CA Technologies, described how the application of model-based testing, specifically incorporating CA Agile Requirements Designer, helped cut down regression testing cycles from 40 days to three days while still testing with high coverage.

He describes how his team use test cases for regression testing and requested that the platform determine the smallest number of tests that would give maximum functional coverage. The model, which took the equivalent of three-person days to construct, selected 40 test cases.

The model took three days to create, and code coverage was 63% as compared to the manual process that required 40 person-days to deliver 55% coverage.

“This puts us in a situation where we know what to not test,” Tyler stated, “we had a functional regression suite with greater efficiency and relative ease of regenerating the test suites from the model. Best of all, we know what the coverage is, and we know what not to test.”

Using this technique, the costs of automating test cases drops rapidly. The time required to complete initial coding or simulation is somewhat equal to manual, but the time and cost for maintaining it is much lower. When automation is generated from the model, keeping the model becomes a much more efficient method of maintaining a test suite.

Start your Free Trial of CA Agile Requirements Designer today and fast track your Testing at the speed of agile.

Related Posts