How many times have we heard below in meetings after a release?

• Why did Testing not find this defect?
• Why did Testing find this defect so late?
• Yes, there were environment issues. But why didn’t Testing finish on time?
• Yes, the code quality was poor. But why didn’t Testing find all the defects?

People attending those meetings forget that there are more people involved in the full delivery than Testing. There were Project Managers, BAs, Solution Designers, Solution Architects, Developers, Testers, Business Representative, Production Support Team, Release Management Team and the Product Owner/Business Sponsor.

Yes, if critical functionality that was clearly defined in the Requirements document does not work in post release, then by ALL Means, fire the Test Manager as he/she takes the blame for that.

However if there are defects found post release which could have slipped through Testing, before pointing fingers, ask these questions:

1. Did business representative or product owner review the scope of testing?
2. Did Testing provide progress report at every step of the process?
3.  Did business run UAT before release?
4. Are the requirements clear enough for anyone to have found the post release defect during the testing cycle?

If any of them returns a NO, then that means that Testing cannot be solely responsible for the post release defect.

We tend to forget that when a defect is raised against application, business will not say Testing missed it. Business will say IT missed it.

However what tends to happen in big organizations is that everyone then scurries to save their own hide and finger-pointing starts.

It is a fact that no application can be defect free. If that was the case, then companies like Google and Microsoft would have had no need to send patches/bug fixes.

No IT division is provided with unlimited resources, unlimited time and unlimited budget to test an application. To meet the timeframe, Test team often has to adopt Risk based testing approach. In the risk based approach, testing scope is defined by the weight and coverage of requirements. There will be more test cases for key requirements, whereas for less critical requirements coverage will be reduced. By ensuring that other stakeholders get to review the scope and testing progress, IT division mitigates the risk to release.

If the entire SDLC is a collaborative process, why post release it becomes a Testing issue?

The answer is the culture within the organisation. And it starts from the top. If the CIO/CTO/CEO, instead of urging teams to work together and fix the issue asap, starts pointing fingers at teams for letting the defect through, then that will rise to a toxic culture and others will follow. As such, sometimes it is necessary to educate the upper management on the SDLC process. However from experience I know that it is easier said than done.

There are plenty of articles on the web that explains how an organization should change its mindset and promote team work instead of pointing fingers.