According to ISTQB regression testing is: “Testing of a previously tested component or system following modification to ensure that defects have not been introduced or have been uncovered in unchanged areas of the software, as a result of the changes made.» http://glossary.istqb.org/search/regression%20testing
Easy peasy – or not
Yes, but what does that really mean.
In my opinion, there is a difference between regression testing to make sure critical functionality is still working and regression testing to find any unpleasant side effects of the change made.
The first type of regression testing I would call Safety Net Testing – making sure that any change made has not introduced any defects so severe that the product should not be shipped.
The second type of regression testing I would call Neighborhood Testing – making sure that the change made did not cause any unpleasant side effects in the areas considered to be likely to be influenced by the change.
The first type of regression testing should be automated, because it is repeatedly executed and well defined. Whereas the second type requires domain knowledge as well as knowledge about the internal and external dependencies. This is a task for human beings.
The first type of regression testing should be executed according to Product Risk. Actually we do not expect to find any defects during this type of testing, but if we do, it implies that the quality of the delivery process should be analyzed. The latter type of testing implies that exploratory testing should be used. And during this type of testing we do expect to find defects.
A symptom of ignoring the first type of regression testing is critical errors in Production. Whereas a symptom of ignoring the second type of regression testing is collateral damage.
