· The re-run of a test with the intention
of checking that was working is still working.
· The re-run of tests to ensure that a system
has not regressed following a change to another part of the system.
· The re-run of tests to ensure that defects
or bugs have not been introduced to the system following a change or fix to the system.
When a change is made to the system
it is quite possible that it can have a knock on effect on any part of the system.
It could be that by making the change
other areas that were previously working now stop working. In fact the system could end up worse than it originally was.
Regression testing is performed to
give the confidence that this has not happened.
It is obvious that performing a full
regression test every time a change is made to a system will be very time consuming and therefore very costly. Ideally we
will want to test everything but in practice it is not always possible. Difficult decisions sometimes need to be made based
on the business risk.
Example
A large number of changes made to
various areas of the system will be a higher risk than a small cosmetic change. If changes have been made to high-risk business
processes, or complicated areas then these will be higher risk and should be included in regression.
Other decisions can also be made to combine test cases or drop repetitive tests completely
depending on the risk to business process.
When a system is first being developed,
changes are frequently being made and many faults are usually found. At this stage the application or system is generally
thought to be unstable.
As time progresses the frequency
of change is less, the faults are less and the application or system becomes more stable.
It is at this point that there is less re-testing and more of regression testing.
Back to Tutorials
