Why Testing Is Necessary

+ As the question raised before at Part 1- Is QC Really Necessary? Here is the very long detail answer looking thru an PM's eyes, my ex-chief at Agile Mobile. But to me, it's just rather simple, it's a MUST not SHOULD, and I'm glad to see that many people these days are aware of this and it's still increasing. Actually, there are many answers you may found on the Internet. And we wouldn't say what is wrong, what is right. But right here, I would just like to point out an idea about this interesting question, here it is..

All know that we have many kinds of testing: functional, integration, performance, unit testing etc. Each type is done by some members, may be it is done by whom implement feature or someone else, may be it is executed by others. In software industry we have two terms Verification and Validation. Verification means build the right thing and validation is build the thing right. Mostly verification activities belong to functional testing and it needs someone takes user role to verify the product to see whether that product meets client’s expectation. It should not be done by developer himself but someone else (I avoid to use QC here, you will know the reason later). And I'm sure it will be better if the job done by the BA team or even the best situation that client involve deeply to project and validate whether team do right or wrong. But BA member is limited also requiring user involve deeply is a illusion, so we need to have third-party side can play the user role and now we have the team named QC. In fact, the major activities of QC team is making sure the quality of product meet client’s expectation not creating test cases, test procedures etc, which is only the tool help QC team to meet that goal. Moreover, we do not need QC think out-side what developers, BA can not think because it is not a requirement to QC team and it depends on each member’s capacity.

In part 1, developer had wrong argument on testing type, he thinks that unit test can cover integration and functional testing, it is incorrect of course. In general, we have only two types of defect related to developer team, they are:

1. Lack of unit test, they can not cover all cases of testing. In almost cases, I can say defects occur by Null Pointer or Wrong Format are lack of unit test.
2. Ambiguous requirement: they understand the requirement wrongly.

The developer’s responsibility must be making sure they perform unit test very well, it is not the major responsibility of QC is catch up defect for developers by lacking of unit test. The major role of QC team is verifying whether the developer understand requirements and implement it correctly. It does not mean the QC is expert than developer in requirements and system. If some defect is posted to DMS (Defect management system), it does not mean developer team do the wrong thing but it means the developer and “simulated” user (QC member) understand the system in different ways. Such defect may be correct and may be not, it depends on the argument between them with the involvement of BA and client if needed.

For each project, the difficulty of functional testing is different. If project is just a e-learning website, it is rather easy to play the end user role but if your project is a development framework the skill of QC sometimes require more than developer skill, especially if QC team is required using gray box testing. So, the thinking that QC member is un-skilled guys that is not un-fair and un-practiced assessment.

So my answer is we all need to have QC team in any projects but we should do understand their responsibility clearly, developer has his job and QC has her job and they are completely different. The skill-set for each roles are different too, so just be professional and support other sides during developing software is the good way instead to have the wrong perception to QC team.

(Source: my ex-chief blog)