After hearing your videocast it occurs to me that perhaps my original article was not clear on one point. I thought I’d clear that up right now.

It is not my intention to imply that the business unit should decide what components and systems will be tested. Clearly, the SQA and testing organization needs to implement the appropriate quality assurance and testing plans, and see that those plans are carried out. The testing group is responsible for developing specific test plans and executing those plans. Likewise, it is the responsibility of the quality assurance group to validate that work, and ensure that the product is in fact being well and thoroughly tested.

However, there are many situations in today’s market where the business places constraints on these processes. We are often required to push software out the door more quickly than desired. In these situations, it is the business unit that must be responsible for this decision. SQA needs to clearly communicate the risks associated with these compromises to the business unit and place accountability for taking the risk squarely with the business unit. In my own experience, a well-educated business unit will often back down, choosing a more conservative route — possibly holding some features for a future release, or extending release dates. Businesses are, by their nature, risk averse. Put this knowledge to use: Make sure the business understands the risks and accepts responsibility for taking them.

My name is Gil Zilberfld. We’ve discussed your post on our webcast “This week in testing”. We’ll be happy if you can comment, and if you like the discussion and content, let us know. And everyone else.

Thanks,

Gil Zilberfeld Typemock