The Production issues when found are first analysed to find the root cause using a CAR (Casual Analysis Report).
Depending upon the analysis we discuss figure out to how the defect has leaked to Production.
one case would be it was never covered in the specifications or it was a one of Business scenario which we as the techinical / IT team did not consider.
another one would be it was missed during testing hence would concentrate on improving the Review part or increasing the application kowledge for getting more test coverage.
This takes place in a meeting where we have both the teams Dev & QA . The blame is never given to any of teh teams instead it is taken/given as a learning and is marked in the checklist for the next release.
Because once the the build moved from "Devoloper to Tester", Tester is responsible forthe bugs.
May be one of the following reason:
1)Tester not written the good test cases or
2)Lack of domain knowledge
3)Communication gap between the "Devoloper & Tester"(Some of the enhancements will be communicate between "Devoloper & client)
First i would suggest to perform an impact analysis on the defect to find what was the cause of the defect.
Then would determine the project & product risk due to this defect.
Usually the lack of communication within the team is the major cause of this kind of issues.
I like the approach Kiran has... we are all professionals. If an organization is spending time hunting for "blame" and associating some sort of disciplinary approach I think it is a wasted effort. Bugs will always slip through for any number of reasons; (accelorated development / testing, reduced testing due to business pressures for release, misunderstanding of specifications, tester abilities).
A triage of incoming issues from the field should identify cause. Any which can be alleviated by a maintenance release or inclusion in a future upgrade should include updating the test cases which allowed it to slip through. The "how" and "why" a bug slips through should be a learning effort in understanding the complexity of an application and documented so that others picking up the future test effort can plug the hole.