Naturally, regression tests are a time and resource intensive process. A QA team will usually need to run [a lot] of test cases in order to cover the most crucial components of the software potentially affected by new changes. That said, it would be just common sense to think regression tests are a natural candidate for automation.
As some may already know, there are several types of regression testing:
- Corrective, usually done when no changes in the code are made, hence implying less run time.
- Retest-all, used when minor changes are made in the code, but covers all scenarios and therefore is time-consuming.
- Selective, focuses on only selected cases of a certain module which may have experienced changes in its code. It’s less time-consuming and facilitates testing of both current and new code simultaneously.
- Progressive, used when minor changes are made in the code. It facilitates testing an updated version of the product without affecting its current features. This does for quite complex configuration and test preconditions.
- Complete, usually done when the code undergoes many changes and no other changes are intended. As it is very effective in finding bugs within a short time span, it is the previous step before the first use can be made by the end user.
- Partial, implies a selection of specific, related modules that are prone to have been affected by changes in the code. It results in saving time when checking for bugs, without the added hindrance to the code.
- Unit, a pillar of the testing process, it focuses on a single unit of code, isolating it from the rest, every time the changes made in the code are completed. It clears the way for the process planning, especially in a Test Driven Development paradigm.
However, all this implies a tester actually knows programming.