Introduction to Software Test – Regression Test
Regression Testing
When you produce a new piece of software, it did not exist before, and therefore there could not be a ‘working version’. However, if you produce a new level of, or fix to, or upgrade to, or otherwise change, existing software which ‘used to work’, there is the possibility that it will ‘no longer work’ after your change. An UNINTENTIONAL change to the functioning of existing software is known as ‘regression’.
Stand out from the Crowd!
40% OFF – Mobile App QA e-Learning Course
You really don’t want existing customers to have their program ‘stop working’ after they upgrade.
Therefore, any update to software should go through ‘Regression Testing’. This can be as part of the Function Test, or System Test, or both, or even be a separate test. It should consist of testcases (preferably ‘all of them’ but a well chosen subset can be adequate) which have been ‘proven to work’ on the previous version(s) of the software (with any which would fail due to DELIBERATE changes to the code removed). And with any new or updated testcases added to the testcase list after the new version is released.
Since ideally, this would be run after any change to the software, automation of these testcases is of significant concern. Having a regression ‘bucket’ or ‘suite’ which can be started by someone with minimal training, which runs itself and validates itself and cleans up after itself, is of significant value. If this is not practical, at least you want to keep the man-hours required to run and evaluate this test to the minimum practical.
The method of automation would depend on the platform on which the test is run, and the characteristics of the program being tested. For instance, a program which runs in ‘batch’ mode might be best served by some form of programming as a shell around the testcases, or perhaps by using a tool which controls the submission of jobs and checks the results by searching for strings in the output and/or analyzing ‘return codes’. Whereas a ‘GUI’ program might be better served using a tool which ‘records’ keystrokes and other inputs during the initial (non-regression) run, then plays them back and does pattern recognition on the resulting screens during regression runs.
By the way, there is another benefit to having a good, easily run regression bucket. Let us say that there is no change to the software, but that a new piece or level of hardware is desired to be supported. Running the regression bucket against the new hardware is a good way to evaluate the compatibility of the software to the new hardware. We called this ‘progression testing’.
The focus of most testing is to verify and validate ‘what was changed’. Regression testing has as its focus to verify and validate ‘what was not (deliberately) changed’.
Previous Post