Should we add Negative Test Cases to Regression Testing?
Adding negative test cases to regression testing
depends upon the project scope and requirements.
However, following are a few key factors that help in
identifying the test cases for your regression test suite:
1. Altered pieces of code are frequently covered: Frequent changes are undertaken in many parts of the
software. These parts are more prone to defects and hence should be included in
the regression suite. Those test cases should be included for functionalities
that have been changed recently.
2. Business-critical functionalities are covered: The core aspects of the software can be identified
based on the business requirements document. All the test cases should be
included in the regression test that covers these core functions. A
traceability matrix can also be used so that all the high-priority cases can be
rounded up.
3. Bugs are yielded frequently: Those test cases should be identified that fail more frequently over
the production cycle. These test cases cover those areas of the software that
usually malfunction after a change or are fragile. The prioritization of these
cases needed to be done and should be added to the regression test suite.
4. Leveraging complex test cases: Complex pathways that involve GUI sequences take care of many of the
system functionalities. As the system becomes complicated, problems may arise
in sequencing. Hence, regression tests should also cover complex test cases.
A risk-based testing approach can be used, wherein the
ranking of test cases is done based on certain factors and then selected based
on priority. These prioritized tests guarantee cost savings, effort and time.
Test cases can be simplified into three classes as
follows:
l Low priority: This comes last in the priority list and should be included based on
necessity
l Medium priority: This includes complex test cases and negative test case scenarios. The
business value can also be significantly impacted by these test cases
l
High priority: Error-prone modules, business-critical
functionalities and those modules that have been recently changed are taken
into consideration.
Comments
Post a Comment