QA vs QC

(we'll try to intersperse my personal/professional history with some more real posts to keep things interesting)


I've been in quality for years, depending upon how you define it.  But that entire time has been in Software QA.  It wasn't until i came to work at my current company that directly manufactures product that i really learned what the difference between QA and QC really was.  


The answer used to be pretty easy.  QA is what software quality insurance folks did, finding bugs in software, reporting them and being a productive part of the process.  QC is what that inspector on the line who got to put his/her sticker on each pair of underwear promising that there are no defects in that particular piece of product.  Sounds similar but different.  QA looks for bugs in the system, QC looks for bugs in one specific iteration produced from the system. 


Turns out that the way that software development has co-opted the term isn't really correct. 
As i've learned to understand it, QC or quality control is indeed the searching for individual defects in a product.  It doesn't limit itself to a specific product iteration.  In looking for bugs in software, you're likely doing QC. 


QA or Quality Assurance, on the other hand, when you look at the use of the term across industry at large is looking at the process that produces a specific, or many product iterations and figuring out how to guarantee that there will be a generally acceptable level of defects at the end of the process.  Ie that may mean putting checks and balances along the process, that may mean doing some measurement at different stages so you don't have as many defects making it to the end.  it might mean revamping all of your lead-in stages so that things work better.  


If you look at software testing, QA would include ensuring that requirements are funneled correctly, get maintained through the life-cycle properly and get tested at the end correctly.  That development process produces reproducible high quality results.  


To people outside of software QA these definitions seem pretty rigidly understood and utilized.  To people in QA they might as well have not existed.  QC is what other people do, QA is what we do. 


As i consider the experience that i've grown over time though i realize that in actuality what has happened is that when i was a Jr QA i mostly did QC but as i grew more senior i tried harder and harder to determine what was causing the problems to occur much more than just finding the problems.  Root Cause investigation became one of the important parts of my days.  Finding ways to get people not to make the same mistake twice became part of my windmills. 


I say windmill because in software QA isn't listened to very strongly for the most part.  QA trying to suggest that project or development methodology should be updated is generally not well received.   Of course i'm generally, loud, obnoxious, argue well and can even be persuasive so my points probably get heard more than most. 


I'm not certain that most QA people are ready to actually do QA work in the external definition but it is without doubt for me that it's needed in software every bit as much as it is in manufacturing.  


That said, i will continue to respect the terminology differences and try to quietly educate people as to what they really mean.  Not the words as much as the concepts.