Lesson Learnt - Requirement Changes in the middle of testing should be taken up as a Change Request

Requirement changes are nothing new to us.

I remember a recent situation.

- I was testing an interface and raised a defect.

- The developer on one application believed that the problem was on the other application side.

- Since this was an interface, the issue had to be resolved on either application.

- The defect fix was finally identified as a requirement change.

However, unfortunately this new requirement was not to be fixed/tested in the next release or a Change Request. It was decided that the current testing should continue and the new requirement be tested as soon as it was fixed. The QA raised the issue that the entire testing that has already finished will need to be repeated after the fix became available.

The project management still decided to continue with the fix in the same release.

Impact - 

1. QA did risk based re-testing after the fix was available. A lot of overtime hours were added to the budget.

2. Since the test scope was pretty much retested in a very short time, this is a risk to the production.

In other words, the project deferred the risk of defects to the production support.

Although in reality, we did not see any critical issues in production but the risk of errors stayed alive for a long time. The risk actually multiplied as the software rolled into 12 pilot stores from one test environment.

Hence, we learnt a lesson. The requirement changes that are identified in the middle of testing should be taken up separately as a separate release or a CR.