Is it Quality Assurance or Quality Control?

 Is there a difference between Quality Control and Quality Assurance?  Just night and day.  Unfortunately, many companies believe they are the same, when in reality the differences are overwhelming.

Quality Control or Black Box Testing is chartered to ensure that the product is going to meet the user’s needs.  Not to only demonstrate that the program runs.  A program can run and still not meet the user’s needs.  The involvement of QC begins with the Project Specification.  How can a tester test if they are not aware of the client’s expectations?

There should be ongoing processes or standards to help differentiate what the client needs and what the client wants or expects.  Clients normally want everything, but are not always willing to pay for them.  These will be discussed in a later article.  The quality control people have to understand in great detail how the client will use the product in their environment.   “It works on my machine” is not acceptable.  Will it work on the client’s machine?  This is the key to the success of the project. QC will also have to test whenever there are changes to the product.  Changes such as enhancements, bug fixes, perceived or otherwise have to be tested and often, there is no Project Manager involved during these processes’  Project management is not always available or assigned to the product after the product has been released and comes back for maintenance.

Quality Assurance on the other hand is really not so much concerned if the product works, but how the product came together.  Were proper processes followed? When it comes time for maintenance will there be notes and references to fall back on?  Have the test scripts and test cases been saved?  Were there any lessons learned during and after the project?  Quality Assurance owns the product from cradle to grave.  Project managers may come and go, but responsibility for ensuring the product is maintainable and reliable during its lifetime rests with QA and QC.

Now let’s look at the differences in more detail.  As an example, let’s say that a tester has uncovered a problem.  The first thing the QC people will do is document the problem.  Failure to do this could mean the problem disappears and no one knows how it was discovered.  The tester documents the problem in the form of a problem report.  They will reference the specific requirement that failed, what the program should have done, what it did do, and why it doesn’t match the specific requirement. They will also include any test scripts and test cases used to uncover the problem.  Over 90 percent of test cases should come from the requirements.  This is why the requirements gathering process is so important.  Then the tester will submit the problem report and go on to the next test.  The tester does not have the time to wait for a response on this problem, so they move on to the next one. All test scripts and test cases need to be saved as we go along. They will be necessary to do regression testing during enhancements and bug fixes.

However, if the cause of the problem is not identified and addressed the problem will reappear later on and again and again.  Money will be saved by uncovering problems and documenting them as the project goes along and not wait until the very end.  Lessons learned is an ongoing process, not just one to be done at the end of the project.   One of the biggest complaints from testers is the lack of time to test.  If they don’t have time to test where will they find the time to work on lessons learned?  They are too busy testing.  However, it is not the quantity of testing that is done, but the quality of the testing efforts.  This is why it is so important for testing to be involved early in the process. 

Now Quality Assurance comes into the picture.  QA will uncover why this problem happened and how it can be prevented in the future.  Now that the problem is resolved the tester will again retest the module or program to ensure it is fixed.  Then they have to re-test all of the modules that might be affected by this fix.  This can be an overwhelming task if the tester and programmer do not have access to a “Traceability Matrix.” 

A Traceability Matrix is a matrix that cross references each program and test case to a specific requirement.  In that way any time a change is made to a particular requirement, the traceability matrix will be able to identify what other programs could be affected by the change.  There is never enough time to retest everything.  Thus, the traceability matrix will ensure that only those programs that might be affected will be retested. The regression testing will reuse those scripts and test cases that have been previously stored so it will not be necessary to rewrite them.  This process is also necessary whenever an enhancement or fix is implemented into an existing product. 

It is the responsibility of the tester to store these test scripts and test cases in a folder that is external to the project.  If the company is looking for repeatability and reusability they will need to have access to these folders on every project.  Don’t store them in the test plan.

Since most QC/Testers are intimately involved in the operation of the product and ensuring it will meet the client’s needs, who will do the administrative portion of the processes?  Again, this is where QA comes in.  They have to interface with everyone involved in the project.  Nothing in the project should be modified with interfacing with the QA group.  QA is concerned with standards, repeatability, and lowering costs.  The QA group doesn’t know how to do many of the things that occur day to day in the processes, but they are chartered to ensure that these processes will remain the same and everyone will use them. 

If you give the same requirement to 10 programmers you will probably end up with 10 different versions on how to do it.  QA’s job is to extract the best one, document it and make it a standard.  QA has to work with other people in each department and solicit how things should be done.  Then they take all these inputs and go through them and decide on the best one.  This best one is then submitted back to the department for final review and when approved it becomes the standard for the group and company.  The process may have to be repeated a few times to ensure that all participants give feedback. 

Soliciting this feedback is crucial to the success of companies.  People come and go, but products remain out there in the field for years to come.  Look at Y2K.  How much money was spent on undocumented processes that were not in danger of failing?  How much money could have been saved if standards were in existence and QC and QA did the right job?

As you can see both Quality Control and Quality Assurance have full time jobs and are very time consuming.  They also require different skills and resources.  Both of these groups work together on the product from cradle to grave.  QA/Tester is a misnomer.  It is very difficult if not impossible for one person to do both jobs EFFECTIVELY.  I have encountered many people who have both responsibilities and most of them admit that they are unable to do both, yet they are assigned that responsibility.  So if they can’t do both, which one will get the higher priority?  That is obvious.  Testing is more important.  Yet is it really?  If we never improve how things are done, will we ever do better?  “Working smarter not harder” is a very realistic expectation.  But how can we work smarter if we haven’t learned from our previous mistakes?  Ongoing documentation on how processes were done is a QA responsibility.  It will save time and money in the long run and the company will become more efficient and profitable.