Regression Testing

The retesting of a software system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the reparations and that newly added features have not created problems with previous versions of the software.

Also referred to as verification testing, regression testing is initiated after a programmer has attempted to fix a recognized problem or has added source code to a program that may have introduced errors. It is to ensure that the newly modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity.

A test that was written when a bug was fixed. It ensure that this specific bug will not occur again. The full name is "non-regression test".

Regression testing is to uncover new errors,in existing functionality after changes have been made to a system,such as functional enhancements or configuration changes.

One of the main reasons for regression testing is that it's often extremely difficult for a programmer to figure out how a change in one part of the software will
echo in other parts of the software.

Common methods of regression testing include rerunning previously run tests and checking whether program behavior
has changed and whether previously fixed faults have re-emerged.

Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.

Experience has shown that as software is fixed, emergence of new and/or reemergence of old faults is quite common.
Sometimes reemergence occurs because a fix gets lost through poor revision control practices (or simple human error in revision control). So new persion who os making changes on top of latest version may not aware 100% about previous versions functionality due to poor revision control.

Frequently, a fix for a problem in one area inadvertently causes a software bug in another area. Finally, often when some feature is redesigned, some of the same mistakes that were made in the original implementation of the feature were made in the redesign. so It's impotent to execute previous test cases also along with new test cases.

software tools allow the testing environment to execute all the regression test cases automatically; For example we can schedule test cases at mercury quality center.

Common strategies are to run such a system after every successful compile (for small projects), every night, or once a week. Those strategies can be automated by an external tool, such as MQC 9.0, HPIT QC 9.2.