As freshly-fried potato slices jostle through the drying vents at Frito-Lay, an electronic eye detects minute discolorations on the golden surfaces. These discolorations are due to normal color variation in potatos, but field tests have shown that Ruffles’ consumers would rather consume a perfectly consistent yellow chip than one that belies its vegetable pedigree.
This is known as Quality Control (QC): The product is finished, ready for shipment, but we give it one last review before we let it go out the door.
As far as I can tell, the entire software industry has misnamed their QC department by calling it Quality Assurance (QA), and in so doing we’ve done ourselves a disservice.
QC does not ensure quality, it only exposes lack of quality. QC can flick bad chips off the line but it cannot tell you why you’re producing so many bad chips. And that of course is the important question. (Answer: Potatoes with too many eyes.)
If we’re serious about “quality assurance,” we have to admit that producing quality software must enter into every step of development from use cases to requirements to design to writing code. All QC can do is notice that quality was not, in fact, “assured.”
This is not to say QC is useless; on the contrary it is necessary. But it’s a finder of problems, not a solver of them. If software quality is a problem, “beefing up QC” is not the answer.
QC could help us find the answer though. We’re bombarded by in-vogue quality techniques — unit tests, code reviews, scrum sprints, pair programming, agile requirements, TDD, BDD, ADD — but which of these would have the most impact for you specifically? Your programmers, your culture, your product? If QC is measuring the nature of the defects that escaped development, you should be able to establish a baseline, try one of these techniques, and measure the effect.
For example, I just attended a conference where Jeff Sutherland showed Scrum delivering fewer defects by an order of magnitude. Who knows whether you would see similar results, but if that’s the claim, QC should be able to measure it!
In the end, all this would be clearer if we called the QC department “QC.” Then “QA” is something else, something everyone should be thinking about and working on.
Either that, or keep calling that department “QA,” but let them do their jobs. That means QA isn’t stuck at the end of the assembly line, powerless to do anything but complain about the product shooting out. Instead they’re involved at every stage, helping to define and develop a testable product.
Just another example of how important it is to name things properly.
Do you have better ideas for what to call these roles? Have you tried sausage-flavored Pringles? Leave a comment!
9 responses to “QA vs. QC”
If only…
This comes up so often I made a small list on my blog about Testing Cliches
True enough! Thanks for sharing.
> Answer: Potatoes with too many eyes
But in software they tell us that many eyes is the way to reduce quality problems.
Actually, in manufacturing at least, Quality Control does provide answers; the "chip flipper" is only one part of the QC system, other parts will include audits of failure rates, QC of raw materials before processing and other systems. The difference with QA is that only samples are tested, not every single item, e.g. with crisps a QA system would only take a sample of crisps every 20 minutes (for example) and check them against acceptable tolerances for flavour, appearance etc. To summarise, check everything = QC, check some = QA. Since QA in software checks every part against the specified limits (you do have specified limits, don’t you?) it is, in fact, QC, but that is the only difference. Any quality system without feedback and adjustment is practically worthless; in your example, if the colour problem was due to the fryer temperature being too high then every single crisp would be blown off the line and no product produced and thus it still wouldn’t produce a quality product out of the end.
Th "Pringles" potato chips as shown in the picture are not made from sliced potato; the chips are produced from a "dough" which consists primarily pulped raw potatoes and various additives. The dough is extruded onto molds to achieve the distinctive shape, hot air dried, sprayed with an oil and flavouring mix, and then baked in a continuous process oven.
The "Ruffles" mentioned in the text are made from whole potatoes, which are sliced in a crinkle pattern and fried.
Mostly I agree with you, and your list of fads is both lol and mostly correct. That said, unit tests should not be in that list: they’re a way of measuring compliance and locating defects. There are parallels in every branch of manufacturing and engineering, and they’re there for a reason: you don’t just do the work, you check that it’s correct before proceeding.
The rest of that stuff, including test driven design, definately fads – some people who have no method find the first method they use to be the greatest thing ever, and get so lost in their desperation to tell everyone about the one true new way (or preaching against those of others – it cuts both ways) that they forget to look for other new improvements.
That said, lots of places just study these things to see what effect is had; some methodologies produce measurable differences, and unit testing is presented in RAND testing as both discovering defects earlier and producing end product with fewer defects total. That other engineering disciplines also follow this – that in fact this is something we’ve known so long that it’s found in our bronze age holy books in parable form such as "measure twice, cut once."
I suggest you give them a try some time.
These things are measurable.
hat said, unit tests should not be in that list: they’re a way of measuring compliance and locating defects. There are parallels in every branch of manufacturing and engineering, and they’re there for a reason: you don’t just do the work
@Paul: It would be nice if in software QC people found root causes, but unfortunately the role of QC is more like the electronic eye (thumbs up/down) and less of the analysis. I think you’ve highlighted the problem with this situation! Thanks.
@ChipConniseur: Wow, that’s awesome of you to supply such detail! Yes, the text is where I did my fact-checking — the picture I just thought was really funny, so hopefully you’ll forgive me in the interest of artistic license.
@John: I agree with you that not every "fad" on the list is a passing fad. In fact, I didn’t mean to imply that anything on the list was bad or fleeting. I’m a huge proponent of unit tests myself. Instead, I merely meant to suggest that there are many ideas, too many ideas, clearly different ones will work with different development groups, and that QC could be useful in identifying which ones are working for a particular group. Also, I agree "these things are measurable," but in practice they are often not actually measured — this is a point that QC could help remedy.
@comment: RE: "eyes reduce quality problems" — ahhh, couldn’t have said it better myself. I think we should start employing that phrase ourselves when pitching our code review software.
Order an ADD http://www.scottberkun.com/blog/2007/asshole-driven-development. Quick and simple