Avoiding ascribing blame for last minute defects without a review

As a software development team reaches the last stages of the development project, the tension levels in the team can suddenly change drastically, mostly increase. There is an anticipation that something may go wrong, something can change the milestones and deadlines. When the team reaches the days before the completion of the development and testing stage, every day of testing brings forth an anticipation, with the leads and managers of the team hoping that the testing is thorough, but that no major defect comes through that could impact the deadlines. 

Any major or high severity defect that comes through near the end deadline has a potential severe impact; the risk of not making a fix is that you release a buggy product, but any fix has the potential to cause an undesired change in functionality or introduce another defect, something that may not be captured easily. With the pressure of deadlines looming, unless more time is given, code reviews and impact testing can try and give the confidence that there are no adverse affects of the fix, but there is always a risk.

What I have seen is that this tension causes people to start flipping out when things start going wrong. So for example, there was a case where a young tester found a severe defect almost near the end of the cycle, and there was no getting around the impact. There was a need to make a fix, evaluate the impact of the fix, do multiple code review cycles and use multiple testers to check the impacted areas, and, and, there was a pushing out of the deadlines by a couple of days. One of the senior managers was very irritated by this, and dressed down the QE lead about why the defect was not caught earlier, almost blaming the QE team for not doing the job thoroughly.

Once the release was done, there was a review team that went through the various development and testing documents, and realized that there was a mixup right from the start, from the developer design documents that were in turn used by the QE team for making their test cases. It was a lucky adhoc test that found the defect. As a byproduct of this review, the senior manager was also advised that such kind of blaming does not help and can end up discouraging those team members who were only doing their jobs, and that too in a proper manner.