Experience has shown that as software is developed, this kind of reemergence
of faults is quite common. Sometimes it occurs because a fix gets lost through
poor revision control practices (or simple human error in revision control), but
often a fix for a problem will be "fragile" in that it fixes the problem in the
narrow case where it was first observed but not in more general cases which may
arise over the lifetime of the software. Finally, it has often been the case
that when some feature is redesigned, the same mistakes will be made in the
redesign that were made in the original implementation of the feature.
Therefore, in most software development situations it is considered good
practice that when a bug is located and fixed, a test that exposes the bug is
recorded and regularly retested after subsequent changes to the program.
Although this may be done through manual testing procedures using programming
techniques, it is often done using automated testing tools. Such a 'test suite'
contains software tools that allow the testing environment to execute all the
regression test cases automatically; some projects even set up automated systems
to automatically re-run all regression tests at specified intervals and report
any regressions. 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 BuildBot.
Regression testing is an integral part of the extreme programming software
development method. In this method, design documents are replaced by extensive,
repeatable, and automated testing of the entire software package at every stage
in the software development cycle.