After a team ships a fix for a payment-calculation defect, they re-run the tests that previously failed (that is re-testing), then run the full regression suite covering the rest of the checkout flow. Regression testing verifies that unchanged areas — such as discount logic and shipping cost calculation — still behave correctly after the modification. In continuous integration, regression tests typically run automatically on every code change.
What is the difference between regression testing and re-testing? Re-testing runs the specific test cases that failed last time to verify the fix worked. Regression testing runs tests on previously tested, unchanged functionality to ensure the change introduced no new defects. Both are needed after a fix.
When is regression testing performed? Whenever the software or its environment changes: new features, bug fixes, configuration changes, or infrastructure updates. The larger the change, the more important the regression coverage.
How much regression testing is enough? Enough to cover the risk of the change. Teams often start with a smoke-testing pass over critical paths, then expand based on change impact and available test automation.
Is regression testing a test level? It is a test type, not a level — regression tests can run at any level, from component testing to system testing, and often appear in multiple phases.
