Regression testing is a type of software testing that verifies that software previously developed and tested still performs correctly after it was changed or interfaced with other software. Changes may include software enhancements, patches, configuration changes, etc. During regression testing, new software bugs or regressions may be uncovered. Sometimes a software change impact analysis is performed to determine what areas could be affected by the proposed changes. These areas may include functional and non-functional areas of the system. [Definition from Wikipedia]

Regression testing is always is a challenge as a feature set grows. Whether manual or automated or both, sometimes regression testing becomes unmanageable in the eyes of the owners and it is abandoned in the face of the effort it represents, and then everyone loses the benefits. Regression testing must be regularly pruned and trained in the most desired/useful direction.

The following are some more specific reasons why regression testing becomes a challenges.

Size of system grows while projects remain similarly constrained

Complexity of system grows while testing practices remain static

Automation efforts are prone to failure

[reference: http://thinktesting.com/articles/regression-testing-strategic-and-risk-driven-can-you-afford-not-to/]

Regression Testing time can be reduced by narrowing down the tests in the regression suite. It can be done by following these steps:

Analyse the changes done, determine the impact at module level and functional level. Based on the Impact Analysis, group the related tests and execute it.

Another technique that I came across during my research on reducing the time for regression testing was reduce, reuse, recycle and recover.

Reduce the regression testing time by creating effective regression test suites that test the changed part of the software, by identifying test cases in the regression test suite that do not need to be rerun on the changed software, and by identifying and removing obsolete test cases.

Reuse test suites created for one version of the software by identifying those test cases that need to be rerun for testing subsequent versions of the software and by computing an effective ordering for running the test cases.

Recycle test cases by monitoring executions to gather test inputs that can be used for retest-ing and by creating unit test cases from system test cases.

Recover test cases by identifying, manipulating, and transforming obsolete test cases, by generating new test cases from old ones, and by repairing test cases when the software changes

[reference: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=5306347]

Assess the impact at a functional/module/component level and reduce the coverage of your regression suite. This can be for both manual and automated tests. We need to identify complete end to end flow rather than individual test cases for regression.

If you have a lot of regression tests because you have a lot of parameters, you might want to give combinatorial testing a shot.



The point of regression testing is to find bugs injected into the system later. Most bugs happen not because some parameter is set to a value. They usually happen when at least two different parameters are involved.



Instead of testing every possible combination of values, test every possible -pair- of values. There are much fewer tests to get this coverage.



If you want to look at a tool, Hexawise would be a great place to start.

Design your regression test suite in such a way that you are able to perform different levels of regression testing while also reducing resource and turnaround requirements.

If you carefully feed and care for your regression test suite you will reap the benefit of continually increasing confidence in the stability and quality of your system through maximized test coverage and ease of execution within your constraints.