You
must retest fixes to ensure that issues have been resolved before development
can progress.
So,
retesting is the act of repeating a test to verify that a found defect
has been correctly fixed.
Regression
testing on the other hand is the act of repeating
other tests in 'parallel' areas to ensure that the applied fix or a change of
code has not introduced other errors or unexpected behaviour.
For
example, if an error is detected in a particular file handling routine then it
might be corrected by a simple change of code. If that code, however, is
utilised in a number of different places throughout the software, the effects
of such a change could be difficult to anticipate. What appears to be a minor
detail could affect a separate module of code elsewhere in the program. A bug
fix could in fact be introducing bugs elsewhere.
You
would be surprised to learn how common this actually is. In empirical studies
it has been estimated that up to 50% of bug fixes actually introduce additional
errors in the code. Given this, it's a wonder that any software project makes
its delivery on time.
Better
processes will reduce this ratio but will never eliminate it. Programmers risk introducing
casual errors every time they place their hands on the keyboard. An inadvertent
slip of a key that replaces a full stop with a comma might not be detected for
weeks but could have serious repercussions.
Regression
testing attempts to mitigate this problem by assessing the ‘area of impact’
affected by a change or a bug fix to see if it has unintended consequences. It
verifies known good behaviour after a change.
