Verification and Validation (V&V) - Different views

Hereby I have collected a bunch of different views/ideas from various software testing related books (I hereby owe credits to the respective authors) and my industry colleagues/peers about the verification and validation concepts being followed in almost all software development/testing/quality departments of various organizations.Welcoming everyone in the software qulaity and testing industry to share your own perception on these terms verification and validation (V&V) so that we all in the industry can have common understanding of these terms/concepts.

Verification:

1. Verification is a Static testing technique/white box testing technique as the workproduct undergoes a review.
2. Verification is the review of documents/code etc (i.e. no real execution happens)
3. Verification is all about "Are we building the product in right way". (Checking whether a right process is followed or not during the development life cycle)
4. Verification is some sort of QA activity (i.e. Process oriented).It talks about processes,standards and guidelines.
5. Verification is "Defect Prevention" based.It checks the process attributes.
6. Verification is the comparison of specified and actual characteristics
7. Verification is the process of confirming that software meets its specifications
8. Verification is the Process of evaluating a system or component to determine whether the products of the given development phase satisfy the conditions imposed at the start of that phase .(Is the system correct to the specification?)

Validation:

1. Validation is a dynamic testing technique/black box testing technique as the work product is executed.
2. Validation is the real execution (give input and check the output so that real execution happens)
3. Validation is all about "Are we building the right product" (Checking whether a right product is made or not as per customer's need)
4. Validation is some sort of QC activity (i.e. Product oriented).It talks about the product.
5. Validation is Defect correction based (detection and control by correction).It checks the product attributes.
6. Validation is the comparison of expected and actual characteristics
7. Validation is the process of confirming that software meets user/customer's requirements
8. Validation is the determination of correctness of the products of software development with respect to the user needs and requirements. (Is this the right specification?)

Testers – Most disliked as well as most liked people in the organization?

In many of the organizations, testers are in fact disliked. This is because developers do not like their mistakes being pointed out by someone else. Tester becomes a bad guy once he/she points out a problem. So most of the development and testing teams fight with each other either on the screen or behind the screen.

Almost in all industries this is termed as “US” vs. “THEM” mentality. Software industry is not an exception to this concept.

Though it looks like the development team dislikes the testing team but internally they are in a position to like the testing team since they need someone to test the product what they have been developed. Without the assurance given by the testers they cannot release the product to the outside world.

At your work place even you can see some development team leads used to fight with you (the testing group) would approach you personally saying like “Hey please test so and so part in the product rigorously”. If he is very much confident in the development work done by his team then what is the necessity to approach the test team seeking to test it rigorously (even without his request testers do their job for what they are being paid)? This clearly reveals that though they dislikes at some point of time they will surely like the test team on few occasions when they are in need.


But as a tester, despite of liking or disliking by the development group, one should deliver his/her testing responsibilities to the best to uncover the defects.

According to me “US” vs. “THEM” Mentality should be present in tester’s mind but with a positive approach and not with an offensive approach against development group i.e. testers should work for the goodness of the project and not for the goodness of the developers.