I believe the test team has a central role as an information resource to many other units, often outside the project team, and it may well allow them a wider perspective that say the developers have.

That said, if the information flow is not reciprocal then I think the likelihood of an OCP is increased. Sales, marketing, executive, legal, are all departments of a company that I can see having unique insight into possible risks of a project. There may be many more depending on the nature of the company and or the nature of the product itself.

I maintain that the best you can do to avoid an OCP is to gather as much information from the resources you have at your disposal, assess the risks you are able to, and circulate said risks to everyone you can identify that matters, (as opposed to presenting testing directions, which may be meaningless to them). Ask them if they can think of any other scenarios that might be a problem and factor those in. Reassess the risks as things change.

That at least allows you to attempt to mitigate the risks you can identify.

I think your analogy is an incomplete one. You say ‘an accounting problem’, but I am talking specifically about an Out of Context Problem.

Let’s extend your analogy - Perhaps something like data loss because an apostrophe in someone’s surname wasn’t handled by their off-the-shelf accounting software?
It might not occur to a finance exec to have the company’s testing team (assuming it had one), put the software through its paces. Even if he or she did, this problem might not crop up immediately. They might have assumed that the product was sufficiently tested by the software company’s test team - not an unreasonable assumption for a non-technical individual to make.

Said exec may feel completely justified in saying ‘there was nothing more I could have done’ if they had taken the appropriate precautions that their training and experience afforded them. Moving forward, I’d be willing to bet said exec would advocate thorough testing of any new software product because, unlike before, he now has a reference that this sort of thing can happen.

But I don’t like the backside-covering strategy (although I’ve done it ) because no other position is knowledgeable enough in testing matters to assess the risks as the tester team.
Presenting a big powerpoint of test directions and asking ‘anyone can say if we missed a point?’ does not diminish the bad-feelings – or responsibility – when a problem comes after the product is released.

If I may try an analogy…
Let’s say the financial executive of a company feels uncertainty on his numbers… he can call all major executives from the other departments (marketing, development, legal…) and show the financial strategy.
After a big accounting problem, it would not make sense for him to say ‘well, you all said it was ok!’ – Because he is the money professional, and even if it is nice to see him sharing his strategy with others, the responsibility is still at his table.

Can you tell a bit more about your experiences with such cases?
How do you conduct the arse-covering session? How was the reaction when a surprise problem arose (if there was any)?

Thanks for the insightful readings!
Shmuel