Comparison of verification & validation and quality assurance view points
By DeviQA on Sat Nov 18 2017 00:00:00 GMT+0000 (Coordinated Universal Time)
The verification and validation technologies used in the design process can identify errors on the early stages of design. Most errors occur at the stage of the formation of the primary specification, but they only appear when testing. Using models for virtual testing on the early stages of design, specialists can reduce the development time to 50%.
Verification, validation and testing operations can be performed at all stages of the design process based on the model.
So it is very important to define what verification and validation are actually.
The two terms "verification" and "validation" often remain misunderstood, which subsequently leads to serious mistakes in quality management and projects. Let's deal with them.
What is written in the ISO standard
The ISO 9000: 2000 standard defines these terms as follows:
"Verification is confirmation on the basis of objective evidence that the established requirements have been met."
"Verification is confirmation on the basis of objective evidence that the requirements intended for a particular use or application have been met."
Such definitions rather confuse specialists than clarify the essence of these concepts. To make it easier for you to work with them, we collected several alternative definitions and sketched out some examples of what verification and validation are. Let us collect definitions from different points of view.
- is the confirmation of the conformity of the final product to predetermined reference requirements; confirms that "you created the product in the way that you intended to do it."
- is the answer to the question "Does the product meet the requirements?".
- is almost always performed by the method of checking (comparing) the characteristics of products with specified requirements, the result is a conclusion about the conformity (or non-compliance) of products.
- is the confirmation that certain requirements have been met.
- confirms that the requirements of the customer (consumer or user of the product), services or systems are satisfied.
- confirms that "you have created the right product"
- is carried out if necessary, is carried out by the method of analysis of prescribed conditions of application and assessment of the conformity of product characteristics to these requirements, the result is the conclusion about the possibility of using the products for specific conditions.
- is a test of how much the software product meets the expectations and needs of users.
So remember Verification is checking. If you checked that requirements were met this is verification testing. From different points of view (which we will see below) requirements are different so pay attention on it. If all requirements were met (again from different points of view) and application works as intended then this is Validation.
Here is a simple example of a bicycle.
- Are there any pedals? - Yes.
"Is there a saddle?" - Yes.
"Is there a chain?" - Yes.
- Is there everything…? - Yes, there's all.
- Is it moving? - No, it's not. The effect of what we have is none.
As you can see, not everything is so difficult with the definitions of verification and validation.
Another thing that should not be forgotten is quality assurance view points>. How, where and why each QA member should look at application?
1. Client’s Point of View:
- Main goals should be reached.
- Release should not be ruined by bugs.
- Release should be in time.
2. End User’s Point of View:
- Software should be user-friendly.
- Even non-use cases should be covered by program with correct errors.
- All use-cases should be covered.
- All errors should be guideful and clear.
3. Purchaser’s Point of View:
- All texts should be without spelling errors.
- If we support different language than translation should be done well.
- There should not be UI bugs.
4. Point of View of a company:
We should not miss any critical bugs.
If we missed some bugs and passed them to production we should prevent such possibility in future.
Here some tips:
#1 Incorrect requirements and design errors should be identified as early as possible. To validate the requirements and determine the properties of the project system, formalizing the functional behavior, it is worthwhile to use system modeling.
#2 A consistent, well-written documentation allows for more efficient evaluation of the development and distribution of tasks among project participants. MathWorks' tools automate the creation of project documentation, test reports and tests, traceability reports, generation of reports with customizable parameters.
#3 MathWorks products allow you to capture project parameters and functional requirements in the modeling environment. The developer can simulate design options and analyze models using formal methods to improve the design and functionality of an unexpected discovery that is problematic to do exclusively with performance models. When Simulink Design Verifier ™ help generate tests for models and parameters are supported.
As you can see each member of the process has his own point of view. I do not say that all these statements are true, just pay attention that this is an example of how QA member should look at application. Train yourself to be not just a TC executor. Train yourself to be able to think as different person which belongs to different species of IT food chain.