Regression vs. Retesting
Regression vs. Retesting
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 QA 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.
It is quite common for regression testing to cover ALL of the product or software under test.
Why? Because programmers are notoriously bad at being able to track and control change in their
software. When they fix a problem they will cause other problems. They generally have no idea of
the impact a change will make, nor can they reliably back-out those changes.
If developers could, with any certainty, specify the exact scope and effects of a change they made then
testing could be confined to the area affected. Woe betide the tester that makes such an assumption
however!
White-Box vs Black-Box testing
Testing of completed units of functional code is known as black-box testing because testers treat the
object as a black-box. They concern themselves with verifying specified input against expected
output and not worrying about the logic of what goes on in between.
User Acceptance Testing (UAT) and Systems Testing are classic example of black-box testing.
White-box or glass-box testing relies on analysing the code itself and the internal logic of the
software. White-box testing is often, but not always, the purview of programmers. It uses
techniques which range from highly technical or technology specific testing through to things like
code inspections.
Although white-box techniques can be used at any stage in a software product's life cycle they
tend to be found in Unit testing activities.
9
