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 just to 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 without knowing 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 the price. The quality control people have to understand in great detail how the client will use the product in its 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 and fixes for bugs — perceived or otherwise — have to be tested. Often, there is no project manager involved during these processes; project management is not always available or assigned to the product after it has been released and comes back for maintenance.

Quality assurance, on the other hand, is concerned less about whether the product works than how it 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.

Start With Quality Control

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, referencing the specific requirement that failed, what the program should have done, what it did do, and why it doesn’t match the specific requirement.

The tester 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.

All test scripts and test cases need to be saved, as they will be necessary to do regression testing during enhancements and bug fixes. 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, rather than waiting 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 sufficient 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 that matters the most. This is why it is so important for testing to be involved early in the process.

Enter Quality Assurance

Quality assurance enters the picture to uncover why a problem occurred and determine how it can be prevented in the future. After the problem is resolved, the tester will again retest the module or program to ensure it is fixed. Then it will be necessary to retest all of the modules that might be affected by the 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. 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 test scripts and test cases in a folder that is external to the project. If the company is looking for repeatability and reusability, it 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. The QA group must interface with everyone involved in the project. Nothing in the project should be modified without 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 it is chartered to ensure that these processes will remain the same, and everyone will use them.

Feedback Is Crucial

If you give the same requirement to 10 programmers, you will probably end up with 10 different versions of how to achieve 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 input on how things should be done. Then, the QA group takes all of these inputs and goes through them and decides on the best one. The best one is then submitted back to the department for final review. When approved, it becomes the standard for the group and the company. The process may have to be repeated a few times to ensure that all participants give feedback.

Soliciting 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?

Both quality control and quality assurance are full-time jobs and are very time-consuming. They 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. People who have both responsibilities almost invariably 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.