Regression Testing in Software: Overview and Methodology
Regression testing is crucial for uncovering new software bugs post changes in a system. Criteria for selecting test cases, including prioritizing based on impact and customer usage, play a vital role. There are various types of tests such as smoke testing and sanity testing involved in regression testing. Prioritizing test cases based on importance ensures successful test executions.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them. When to do regression testing? 1. Reasonable amount of initial testing is already carried out. 2. A good number of defects have been fixed 3. Defect fixes that can produce side-effects are taken care of. 4. Regression testing should be done periodically.
Methodology for RT 1. Performing an initial smoke or sanity test
Smoke testing Smoke testing term came from hardware testing, when you get new hardware and power it ON if smoke comes out then you do not proceed with its testing. In software testing, a smoke test is run on application initial builds to ascertain application most critical areas are working correctly and application is ready for thorough testing. Sanity testing Once a new build is received after minor changes, instead of starting its complete testing sanity test is conducted to make sure previous defects has been fixed and new issues have not been introduces by these fixes. Sanity testing is a subset of regression testing.
2. Understanding the criteria for selecting test cases Two approaches for selecting test cases 1. Constant set of regression tests that are run for every build or change. 2. Selecting test cases dynamically Selecting test cases requires knowledge of 1. Defect fixes and changes made in the current build 2. The way to test the current changes 3. The impact that the current changes may have on other parts of the system and 4. The ways of testing the other impacted parts.
Include test cases that have produced the maximum defects in the past. Include test cases for a functionality in which a change has been made. Include test cases in which problems are reported. Include test cases which covers the mandatory requirements of the customer. Include test cases to test the positive test conditions. Include the area which is highly visible to the users NOTE:RT should focus more on the impact of defect fixes than on the critically of the defect itself.
3. Classifying test cases It is important to know the relative priority of test cases for a successful test execution Fixing priority based on importance and customer usage Priority 0- These are called sanity test cases checks the basic functionality Run for accepting the build for further testing Run when a product goes through major changes It delivers a very high project values to Development teams and the customers
Priority 1 It delivers a very high project values to Development teams and the customers. Priority 2 It delivers moderate project values. ( it will be used for regression testing on a need basis)
4. Methodology for selecting test cases Critical and impact of defect fixes Selection of test cases Additional test cases Low Few test cases from TCDB ( TEST CASE DATA BASE) - Medium All Priority 0 and Priority 1 test cases Test cases from priority 2 is desirable but not necessary High All Priority 0 and Priority 1 test cases Subset of Priority 2 test cases
Critically Impact Low Medium High P0 Subset P0 All P0 All P1 Subset P1 All P1 All P2 Subset P2 Very few P2 Subset
If there is not enough time and the risk of not doing an impact analysis is low, then alternative methodology 1. Regress all: P-0,1,2 test case are run- all test cases are executed. 2. Priority based regression : P- 0,1,2 are run in order based on the availability of time- when to stop is based on availability of time. 3. Regress changes: code changes are compared to the last cycle of testing and test cases are selected based on their impact on the code. 4. Random regression: Random test cases 5. Context based dynamic regression: Few P-0 test cases are selected
5. Resetting the test cases for regression testing Selecting test cases based on test case result history Information about test cases are recorded in each cycle is called TCRH. IN MANY ORGANIZATION NOT ALL THE TYPES OF TESTING NOR ALL THE TEST CASES ARE REPEATED FOR EACH CYCLE. TEST CASE HISTORY WHAT TEST CASES AND WHEN?? RESET PROCEDURE : THE METHOD OR PROCEDURE THAT USES TCH TO INDICATE SOME OF THE TEST CASES BE SELECTED FOR REGRESSION TESTING IS CALLED RESET PROCEDURE.
POINTS TO BE CONSIDERED RETESTING WHEN THERE IS MAJOR CHANGES IN THE PRODUCT. CHANGES IN THE BUILD PROCEDURE WHICH AFFECTS THE PRODUCT SOME OF THE TEST CASES NOT EXECUTED FOR A LONG PERIOD WHEN THE PRODUCT IS IN THE FINAL REGRESSION TEST CYCLE WITH A FEW SELECTED TEST CASES. EXPECTED RESULT OF THE TEST CASES IS QUIET DIFFERENT FROM THE PREVIOUS TEST CYCLE.
6. Concluding the results of regression testing
