The document discusses regression testing, which involves re-testing software features after changes to ensure existing functionality still works as intended. It describes strategies like running all or prioritized tests, and best practices like mapping defects to test cases and executing a test bed daily. Regression testing is important after fixes, enhancements or new functionality is added to prevent unintended breaks.

1. Regression testing

2. • Software under goes constant changes.
• Such changes are necessitated because of
– defects to be fixed,
– enhancement to be made to existing functionality
– new functionality to be added
• Important to ensure
– Change or addition work as designed
– Changes or additions do not break something that
is already working and should continue to work

3. • Regression testing is designed to address those purpose
• Regression testing is always done to verify that modified code
does not break the existing functionality of the application
and works within the requirements of the system
• There are mostly two strategies to regression testing,
– to run all tests and
– always run a subset of tests based on a test case
prioritization technique.
• Regression testing is the re-testing of features to make safe
that features working earlier are still working fine as desired.
• It is executed when any new build comes to QA, which has
bug fixes in it or during releasing cycles (Alpha, Beta or GA) to
originate always the endurance of product.

4. Types of regression testing

5. • Build
– An aggregation of all defect fixes and features that are
present in the product
• Types
– Regular regression testing
• Is done between test cycles to ensure that the defect fixes
that are done and functionality that were working with the
earlier test cycle continue to work
• Can use more than one product build for test cases
– Final regression testing
• Is done to validate the final build before release.

6. • Cook time
– specific period of time required to conduct Final
regression test cycle
– Final regression are executed complete duration
of cook time to ensure time bound defects are
identified.

7. When to do regression testing
• Whenever changes happen to software
– A reasonable amount of initial testing is already
carried out
– A good number of defects have been fixed
– Defects fixes that can produce side effects are
taken care of.
• Regression testing done between test cycle to
find out if software delivered is as good or
better than the builds received in the past .

8. How to do regression testing

9. • Performing an initial ―Smoke‖ or ―Sanity‖ test
• Understanding the criteria for selecting the test
cases
• Classifying the test cases into different priorities
• A methodology for selecting test cases
• Resetting the test cases for test execution
• Concluding the results of a regression cycle

10. Performing an initial Smoke or Sanity‖
test
• Whenever changes made to a product it should first be
made sure that nothing basic break
• Smoke testing consists of
– Identifying the basic functionality that a product must
satisfy
– Designing test cases to ensure these basic functionality
works and packaging them into a smoke suite.
– Ensuring that every time product is built, this suite is run
successfully before anything is run
– If this suite fails, escalating to the developer to identify the
changes and perhaps changes or roll back the changes to
state where the smoke test suite succeed

11. • To make sure that problem in smoke testing
are detected upfront, some organization
mandate that anytime developer make a
changes , they should run the smoke test

12. Understanding the criteria for
selecting the test cases
• First approach
– Choose a constant test cases that run for every build
or changes
• Second approach
– Select test cases dynamically for every build
– This approach need of knowledge of
• Defect fixes and changes made in current build
• The ways to test the current changes
• Impact that current changes made on pther part of system
• The ways to test the other impacted parts

13. • Criteria for selecting test cases
– Include test cases that have produced the
maximum defect in the past
– Include test cases in which problems are reported
– Include test cases that test the end-to-end
behavior of the application or the product
– Include test cases to test the positive test
condition
– Includes the area which is highly visible to the
users.

14. • The selection of test cases depends on impact
of defects fixes that criticality of the defect.
• A minor defects can result n major side effect
and defects fix for a critical defect can have
minor side effect
• Selecting regression test case is a continuous
process, test cases need to be evaluated for
their suitability.

15. Classifying the test cases into different
priorities
• Priorities the test cases based on importance and
customer usage
– Priority 0: these test cases can be called sanity test
cases which check basic functionality and are run for
accepting the build of further testing.
– Priority 1: Uses the basic and normal setup and these
test cases deliver high project value to both
development team and to customers.
– Priority 2: test cases deliver moderate project value.
They are executed as part of testing cycle and selected
for regression testing on need basis.

16. A methodology for selecting test cases
• Case 1: If the criticality and impact of the defect
fixes are low, then it is enough that a test
engineer selects a few test cases from test case
database
• Case 2: If the criticality and impact of the defect
fixes are medium, then it is needed to execute all
priority-0 and priority-1 test cases.
• Case 3: If the criticality and impact of the defect
fixes are high, then it is needed to execute all
priority-0 and priority-1 and a carefully selected
subset of priority-2.

17. • Alternative methodologies
– Regress all
• All priority test cases are rerun
– Priority based regression
• All priority test cases are run in order, based on availability of time
– Regress changes
• Code changes are compared to last cycle of testing and test cases
selected based on their impact on code
– Random regression
• Random test cases are selected
– Context based dynamic regression
• Few priority test case selected based on context created by the
analysis of those test cases after execution and outcome

18. Resetting the test cases for test
execution
• Test case result history
– A record of what test cases were executed in which cycle,
their result, and related information.
• Reset procedure
– Method / procedure to uses test case result history to
indicate some of the test cases be selected for regression
testing.
• Resetting test case is a setting a flag called not run or
execute again
• It reduce the risk involved in testing defect fixes by
making the testers go through all the test cases

19. • Rerun flagged test cases used to gain the confidence in
product by testing more times
• Reset flagged test cases says that test result can be different
from past and only after these test cases are executed can we
know the result of regression and release.
• Consideration on resetting of test cases
– major changes in product
– When some test cases are not executed for long time
– Product in final regression test cycle with few selected test case
– Expected results of test case could be quite different from previous
– Existing functionality of product removed
– Test cases continuously produce positive result

20. • Uses of reset flag for regression testing in
various phase
– Component test cycle
• Uses only priority 0 test case, so priority 0 test cases
are reset
– Integration test cycle
• Priority 0, 1
– System test phase
• Priority 2 executed after priority 1. so priority 0,1,2 are
reset

21. Concluding the results of a regression
cycle
• Monitor the result of regression to now how well
their defects are fixes works in product.
• Test manager can compare their previous result of
the test cases to conclude whether regression are
successful or not.

22. Best Practices in Regression Testing
• Practice 1 Regression can be used for all types of
releases
• Practice 2 Mapping defect identifiers with test
cases improves regression quality
• Practice 3 Create and execute regression test bed
daily
• Practice 4 Ask your best test engineer to select
the test cases
• Practice 5 Detect defects, and protect your
product from defects and defect fixes