I don’t wanted to hijack the another tread, so let me start with quote from it (Frits Bos commented my signature, see below):
Originally posted by Frits Bos: What I think testing is about is more the art of a destructive diagnosis turned into constructive conflict.
<font size="2" face="Verdana, Arial, Helvetica">The signature was created while I was possessed by the book “Five dysfunctions of a team”. I tend to agree with you, but not completely. Just turned out into an idea that:
QA (with excluded QC): The art of a so in-depth review that it tends to provoke constructive conflict. Which it the first step toward process improvement.
The art is to avoid conflict on personal level – in this case review will be perceived as destructive diagnose.
QC: The art of a so destructive diagnosis that if exposes flaws.
The art is to make constructive destructions, not the chaotic ones – this will help to avid conflict on personal level.
Hope to hear a lot of argues [img]images/icons/smile.gif[/img]
When I originally commented on the signature line it struck me that for QA/QC to work we need to be aware of two things:
To the developers/analysts the very nature of the work will come across as a destructive diagnosis, simply because we will focus on everything that is wrong: with requirements, design, code, or the documentation for that matter. We don't tend to write status reports that say, "Damn good work, 98% fault free", we say "A 2% error rate found, acceptable for deployment".
Any time you point out that something is wrong a conflict ensues. The goal is to keep that from becoming personal: keep it functional. It is not "You have a problem", it is "We may be able to fix this problem if..." to make a difference in getting results. If I start off positive with a comment of "Wow, only 2% errors" then the usual result is a developer receptive to hear what I am asking to get fixed. If I start off negative with a comment of "Well, 98% is better than nothing" I presume the conversation has pretty well ended at that point.
Please note: extremes used in above examples only to illustrate a point. Use examples at own risk.