I love analogies.  If you can paint a good picture in someone’s head to illustrate your point, it will stay with them longer than any of your words can.   Many people are visual thinkers and this can be a far more effective way to communicate.

My perfect analogy for Quality Control (QC) verse Quality Assurance (QA) is that QC is like going to the hospital, whereas QA is like going to the gym.   Most companies acknowledge the need for QC but QA is often a harder sell, same way we have trouble sometimes convincing ourselves to go to the gym!  We know it is good for us but sometime we are too busy or too lazy.  Sooner or later, it will catch up and put us in the hospital.

QC = Hospital

Quality Control (QC) is the investigation to verify the presence of defects.  Whatever problems we are looking for, they are already there in the product, we are simply hunting them down and determining how to fix them.  Same thing with the hospital – you are running diagnostics on the symptoms, determining the treatment and fixing the illness.  QC has no role in preventing the defects from being created, it only reacts to what is already done.  Some activities done by QC are:

  1. Functional Testing (White Box and Black Box)
  2. System Integration Testing
  3. Performance Testing
  4. Stress Testing
  5. User Acceptance Testing

None of these activities impact or change the SDLC or how the product is produced, they are simply an end stage in the SDLC .  It can only react to what is aready done and improve the quality of the product after it has been produced.

QA = Gym

Quality Assurance (QA) is all about prevention.  What we put into our product through our processes predicts the outcome of the final product (garbage in, garbage out).  By creating better software processes, we can actually improve the quality from the very begining of the SDLC and prevent the defects from ever being created, the same way as regular exercise and proper diet can prevent illnesses.    Some of the areas where QA evaluations can have a huge improvement in the overall health of the product are:

  1. Better project scope definitions
  2. Detailed and effective requirements gathering
  3. Improved design specifications
  4. Traceablity from requirements through the SLDC process to test cases
  5. Strict guidelines for source control and code build procedures
  6. Test Design reviews by a variety of departments, not just QC (for instance – involving development, business analysts and architecture teams)
  7. Company wide User Acceptance Testing
  8. Improved training documentation and user manuals
  9. Lessons Learned activities for continuous improvement

Quality Assurance should never be an activity for the QA department alone.  Every department should participate in not only improving their own departmental processes but also providing input to the improvements of all facets of the software life cycle.

Often departments overlook how much their activities impact the other departments and what happens when they fail to communicate.  I often describe this as a relay race where the runners can’t pass a baton!  Each runner might be a great runner but if they can’t pass the damn baton, they will ultimately lose.

Just as in life we need both hospitals and gyms, we need both QA and QC in the SDLC.  However, the more effective our QA efforts are, the faster we can get through QC and there will be fewer and less severe defects.

In order to be truly effective, it is critical that Quality Assurance  is a philosophy that is endorsed and actively supported by all departments throughout the SDLC.