How objective is your qc?

QC people have a special role in the development process. Part of this role is being involved in different activities throughout the entire development process. Starting from the time when requirements are gathered, when initial design is made, and until the end of each iteration, the QC people must observe and gather information about the system under development. This is crucial to the completeness and correctness of the QC activity. A QC Engineer can’t be expected to jump into the project just before the actual testing starts. She must be aware of the evolution of the requirements and the system itself (including the way it is designed and implemented) in order to create an effective test plan, and build correct tests.

However, at the same time, it is crucial to maintain the objectivity of the QC people. Since the QC engineer is so involved in the development process, it is easy to forget that if she will be too close to the developers, the result of the QC process might not reflect the real quality of the product.

If, for example, something in the requirements is vague, the QC engineer might be tempted to ask the developer for the “correct interpretation” of this issue. But, it is the QC engineer’s role to verify that the developer’s interpretation of the requirements is correct. How can she use the developer’s interpretation to build an objective test?

This is a simple example for what could happen when QC and developers are too close. Doing extensive testing based on what the developers gathered from the requirements, is bound to catch only coding errors. Logical errors in the functionality of the system are most likely to be left in the code under these circumstances.

The way to solve this conflict, is having great self discipline. QC people should be involved in the development, but they should think twice about whom are they talking to when having questions about the requirements of the product. The best person to ask such questions is the same person defining the requirements.

It is important to note that the QC people should not be completely isolated from the development team. The QC engineer could benefit a great deal from discussing the structure of the code and the design details with the developers. This kind of discussion might give her ideas for more test cases, for example. The difference between discussing the structure of the code and discussing the interpretation of the requirements is that verifying the latter is in fact the purpose of the QC process.