Regression testing can be defined as retesting portions of a product based upon the risk introduced by the inclusion of new features and changes to existing ones to ensure that other functionality did not break. Typically there is not time to retest everything due to deadlines or size of the product; therefore regression testing becomes a function of risk and time. One way of addressing time-constraints can be managed by performing a modified-regression test during functional testing and identifying core-regression testing once code is locked down.

This article discusses different approaches to assessing risk that can be used to develop both a modified- and core-regression strategy. It is important to re-evaluate regression testing approaches to keep them fresh and current. An out-dated strategy provides a false sense of security that regression bugs will be found. Regression testing trategies can be based upon a 3-risks approach: coding changes; history of bugs; and main features.

Risk 1: Coding Changes

Working with senior developers is important to understand the risk level of the code changes to review functionality that may break. Potential discussions can include the experience level of the developer; the history of the feature; and coding scope. The experience level of the developer in regards to the coding or technology can help determine the extent of regression testing required. If an existing feature was modified, knowing the history of problems can help determine impact upon existing code. The coding scope considers how extensive the code base was changed such as localized or extensive changes touching many areas of the product.

A formal review with the senior developers may not always be possible, in those cases be sure to ask them to identify the areas they feel are at risk.

Risk 2: History of Fixed Bugs

Understanding the history of bugs fixed and retested can identify weaker areas that should continue to be re-tested until there is a history of stability. Determine if there are areas that tend to be buggy or individual bugs that are deemed important to be added to regression testing.

Risk 3: Main Features

A set of main features can be defined that is tested during every regression cycle. This can be based upon the core functionality and what is important to the client. Working with product management can be beneficial in understanding what functionality the client frequently uses. This assessment should be reviewed periodically to determine if anything should be added or removed.

Modified-Regression Testing During Functional Testing

While performing functional testing, it can be beneficial to perform a modified-regression test around the code change to identify initial problems. Often during functional testing there is not sufficient time to fully regress a feature while performing other testing assignments. In these cases, a modified- regression can be performed based upon the assessment of the 3-risks approach to determine high-risk areas. The outcome of this testing can be helpful in determining how to allocate time re-testing functionality during core-regression testing.

Core-Regression Testing At Code Lock

A core-regression strategy can be defined based upon analyzing the information gathered during the 3-risks approach and the regression bugs found during functional testing. Based upon this risk-assessment, a spreadsheet can be created outlining tests to perform and their risk or priority level. This spreadsheet can be assembled throughout functional testing as risks are identified and finalized before core-regression testing begins. Assigning a priority is important to ensure the items are retested in order of importance based upon the analysis.

Conclusion

Due to time-constraints and product size, it is not always possible to perform regression testing across all features. To address this problem, regression testing becomes a function of risk and time by balancing the risks introduced through code changes, understanding areas of instability, and identifying features that are critical to the customer. By bringing a modified-regression approach into functional testing allows an earlier understanding of regression-bugs. This information can be valuable in defining risk and priority levels in core-regression testing which is designed to retest at-risk areas. A regression strategy should be reviewed periodically to ensure it evolves with the product’s changing risks to keep the approach relevant in order to find new regression bugs.

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Regression-based-Testing.jpg?fit=310%2C222&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Regression-based-Testing.jpg?resize=150%2C111&ssl=1Bernice Niel RuhlandArticlesTesting ArticleRegression testing can be defined as retesting portions of a product based upon the risk introduced by the inclusion of new features and changes to existing ones to ensure that other functionality did not break. Typically there is not time to retest everything due to deadlines or size of...