Carnegie Quality

I recently posted a template for a risk management plan. The plan discusses, among other things, how to identify risk. I thought I would spend some space talking about identifying risk from a testing perspective.

But first let me ask a question about why we do risk identification. Is it possible to release a defect-free product? I suppose it depends on your point of view, but speaking practically, the answer is no. In the real-world we have constraints – limited testers, limited schedule, not enough tools, etc… So it is with this realization – no software can be perfect – that risk identification becomes so critical.
Continue Reading »

Hot off the presses – a risk register template that you can get over here.

I’ve just posted a template for a risk management plan – you can grab it over here.

Why I am posting a risk management plan on a site about testing? Well, for a couple of reasons. First, I’m trying not to limit information on my blog to testing only – I’d like to incorporate information on quality assurance, which I feel is much broader than just testing. Second, while I agree that risk management is ultimately the project manager’s responsibility, I believe that quality assurance/testers have unique insight into risk, and therefore should play a key role within risk management. And finally, I believe that many project managers don’t do risk management (or don’t do it well), and if you find yourself in this situation, it’s better to step up and make sure that risk management is done rather than just shrugging your shoulders and saying “it’s not my job”.

I stumbled across an old article that I hadn’t seen before from QualityProgramming.org called “Bug Analysis: Laying the Ground for Bug Prevention” (8/15/11 update – link appears to be broken now). It’s a very good article on how testing can enable continuous improvement.

A couple of thoughts after I read this article:

• In my experience, it’s the role of the developer to assess the reason for the defect, not the tester. I would never go through someone’s code – I wouldn’t know what to look for! Though I understand that others are much more technical in nature and enjoy this.
• While the activities that are described in the article are spot on, I think there is too much emphasis placed on the Quality Control (testing) team. The real owner of this function is Quality Assurance. QA is responsible for making sure there are lessons learned – doesn’t mean they will do all the work, but they need to be driving this.
• I’ve had mixed experiences doing these things myself. Many times I’ve done defect analysis and root cause analysis; documented my findings with charts and graphs; and presented them to project management/development to discover not much enthusiasm. Maybe it’s me, but I hope not! What have others experienced?

I’ve just posted a new Test Plan Template. Feedback is always appreciated, so feel free to leave a comment.