When it comes to software development
process, even a small change can bring forth major unexpected changes in the
functionality of the whole system. Here comes the role of the regression
testing. Regression testing is done to check if the existing functionality is
rendered unaltered even by the tweaks made to abolish the bugs. It also
provides with proof that the eradicated bugs are not brought to life again.
Regression testing is done whenever any kind
of changes are applied to the system, so as to check if the system is working
properly as desired. Bigger the changes made, bigger will be the possibility of
the software functionality to be affected. Basically regression testing has two
steps:
1. Conducting the already performed
tests.
2. Checking the results of the tests
with the previously available results to check if the system is up and running
and what new bugs have developed which needs to be eradicated to make the
software function well.
The regression tests are performed from time
to time in patches to save both time and money on the testing process by
preventing the errors to pile up at the end.
Various software testers take different
approaches towards the regression testing of software available to them. While
a part of the tester prefers testing the whole system after a certain amount of
development is done, another set prefers testing the software every time a
small change is made in the source code. In a way the later method is better as
particular software is capable of showing completely surprising changes in the
system which can be sparsely related to the changes made to the system.
Luckily, (thanks to the technology available these days) testers can now create
a library of various tests with the previously available data from functional
tests, unit tests, integration tests, build verification tests or any other
tests which helps in verifying that the system is performing as desired.
With the advent of automatic testing of
software, regression testing has been made easier. Now a days a set of tests
can be scripted with the help of codes and with just a few clicks of the mouse,
these tests can be performed on the software under examination to check the
validity of the system and the status of the abolished bugs. Although this
automation helps in stress removal from the testers, it has some shortcomings
too. When you are performing the same test over and over again, there are
chances that the regression test system will become a standstill. At times it
may also happen that the developers trick the automated regression test system
to overlook certain errors and in this way your system will end up overlooking
most of the errors. So, even if the automation saves a lot of time and energy,
from time to time, manual inputs are needed to keep the system up and running.
In order to get the most out of regression
testing of software, testers have to strike a balance in between the automation
of the process and the manual aspect of the test. Also, regression testing should
be introduced at an early stage of the software development life cycle so that
maximum test coverage of the software can be achieved and piling up of the
system can be avoided.
Thanks for sharing your views.regression testing is an important part of STLC but should be done once the product is stable to save some time. It has benefits in early stages but would be possible if there is enough time or automation is available.
ReplyDeleteRegression should be done post progression cycle. Automated tests should be run against all new builds promoted to test environment. Regression should only focus on areas impacted by changes done during development cycle. Manual testing + acceptance testing should be used for regression cycle.
ReplyDelete