Carnegie Quality

As testing professionals, we face problems nearly every day. A key testing resource becomes unavailable. The delivery date to test slips by 2 days, but the test dates remain frozen. Project management needs an assessment on project quality a day after the code reaches test. I could go on – but you get the picture.

In this post, I’ll discuss some common techniques for analyzing and identifying solutions – and also provide some links to additional information.

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?

You have probably heard both the terms Quality Assurance and Quality Control. But did you know that there is a difference between the two? In this post I’ll do a quick description and contrast of the two. For further ready, I recommend ASQ’s The Certified Quality Manager Handbook.

Quality Control (QC)

Let’s start with Quality Control – if you have a testing background, this is probably what you’ve been doing all along. ASQ describes QC as “the operational techniques and activities used to fulfill requirements for quality.” The QC function is a gate-keeper – it prevents defective products or services from being released. In the software arena, QC is a set of validation and verification (or V&V) activities. Don’t fall into the trap of thinking that this just means software testing – it doesn’t. Verification takes place (or should, at least) at every stage of the software development life-cycle and should include reviews, inspections, and walkthroughs.

Quality Assurance (QA)

QA is a bit harder for some to understand, and is frequently incorrectly used to refer to QC activities. ASQ describes QA as “all the planned and systematic activities implemented within the quality system that can be demonstrated to provide confidence that a product or service will fulfill requirements for quality.” Some key words to consider in that definition are planned and systematic. QA takes place throughout the software development life-cycle, and is not limited to verification activities. QA involves consideration of risk, budget, resource plans, and schedules. The primary objectives of QA are: 1) reduce the rate of deliverables that do not meet quality targets, and 2) reduce the costs of meeting quality objectives. Remember, validation and verification costs are high because they normally require re-work. It is much cheaper to identify problems early in the process, improve your overall processes to reduce non-conformity, and/or consider alternative approaches that reduce risk.