• Personally, I think having the QA Team in design meetings is one of the most valuable things that can be done in a project provided that a true bi-directional dialog can be done. I don't believe in holding back any "Black Box" technology from the QA Team because they can provide invaluable insite that Developers and Planners will sometimes miss simply because they're too close to the problem and also have the tendency to only think "happy path" when it comes to testing.

    That brings us to your subject of a QA person getting "pissed off" in a design meeting. "It Depends" on why that person was "pissed off". If it was only because they suddenly have more work to do because they need to change their test plans, then that person was [font="Arial Black"]might [/font]be out of line. Just remember that such changes can make the QA Team "look bad" because such changes mean that they're going to get the product to test later but no one considers the schedule they're being held to. If that's what the real gripe was, then the "piss off" needs to be carefully listened to because it's a real problem that needs to be addressed or bad product could go out the door.

    Learn to embrace such conflicts in a thoughtful manner. There's almost always something good that will come out of them because conflict can be the leading cause of innovation. A room full of "yes-men" may be similar to a room full of Lemmings ready to follow the leader over the cliff. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)