What is a software regression?

A software is not working as how it works before.

All bug should be reviewed and the regressions should be identified.

Identifying and fixing regression issues is important as it involves the creditability of the company and the products and it generates frustration to the users of the software.

A development team that generates the software regression may have process or quality issues.

Development managers should monitor the trend of the regressions reported.
Developers should analyze the root cause of the regression.  Which product feature changes or which bug fixes caused the software regression.

If a software is shipped with software regression, it means that there may be a test case missing is the regression testing.

Regression Analysis and Resolution Lifecycle:

• Customer file a service request
• Customer support files a bug
• While the developer is analyzing the issue, if the defect is confirmed and the developer suspects that there is a software regression, flag the bug with the regression status as 'Candidate'
• If the problem exists before in the GA version and the current version, it is not a regression, the regression status should be set as 'Not a regression'  It is a problem not previous caught.
• After further analysis, and the bug or code change that causes the regression is identified, the regression status should be set to 'Confirmed'.  The original bug number(s) should be recorded. A comment should be given to describe why a regression happens.  "Lack of training', 'Missing in the design', 'Process Improvement', etc. 

Regression test related lifecycle

• The regression test status should be recorded to indicate whether a test should be created.
• After the regression test is created, the regression test can be closed from the QA perspective.

This is the close loop analysis from QA perspective.