The testing of software from not only a process and load perspective, but also with the variance of data permutations and combinations to ensure that it will handle all data scenarios that it will encounter during its lifetime, especially when a part of the software has changed.

Regression, by definition means a repetition of the entire test effort. There is a common practice to do a regression test even if a small module within your application or application framework has changed. This is to ensure that not only the affected module or unit of code, but also all other pieces of the framework that are likely to interact with this module are tested, and that they are verified to work as they were before this change happened. One rule of thumb is that if you have a method in place with a specific signature and this method has been in the codebase for a while, do not change the method signature, even if you dont see a compilation error. This is a DLL world, and someone, somewhere has code that uses your method or class. Regression testing should not just test applications/modules in question, but the entire enterprise codebase (Intentionally redundant).

Another reason to regress, is that developers tend to work with very small units of arbitrary test data during their testing, and when the same unit of code is put through a much wider data regression, the code fails. A common example is a customer search screen which accepts first name, last name, city, state and/or zip to do a customer search. Unit testing was completed and even integrated testing was completed. When we did a test with a huge list of real customers, it broke when the customer "Jason O'Daniels" was passed to the module. Of course nobody anticipated a last name with a single quote - but that is the reason to regress - over and over, again and again.

They say - Try, Try, Try again till you succeed. We say - Try, Try, Try again till you fail.