Veridation & Valification

There are some words that many people get confused. Something effective successfully achieves its intention and something efficient does it with maximum productivity. If you affect something, then you’ve had an effect on it. Some people don’t know the differences between these pairs of words and don’t want to, their brains must have a problem if they’re thinking like that. 

“dsc04080.jpg” flickr photo by mlinksva shared into the public domain using (CC0)

I didn’t know this, but “verification and validation” (also known as “independent verification and validation”) is a common process in which a service, product or system is accepted after it has met all of its requirements and specifications. The same applies for software, but obviously, the implications are different, and for this entry I will try and explain what are the particularities of this process when applied to software, which is sometimes called software quality control.

I mentioned the similar words in the first paragraph because, even if verification and validation may sound similar, they’re not the same. I decided to include the other name for verification and validation that adds independent at the beginning because it’s there for a reason. It’s important to tell the difference between them before we even begin with the process itself, since they try to achieve different things. This website already provides us with definitions for both of this words AND with important points that each of them need for the V&V process.

Verification. Its objective is to ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements. To know if we’ve fulfilled the objective we ask the question “Are we building the product right?”.

Validation. Its objective is to ensure that the product actually meets the user’s needs and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment. To know if we’ve fulfilled the objective we ask the question “Are we building the right product?”.

Knowing these definitions may help you realize that there can be one without the other, but you must have in mind that both validation and verification are needed to ensure that a product passes quality control.

There are some activities that are usually related to the V&V process. I actually only found a few, but they seem to represent the majority of the whole thing. The one that seems more representative of the whole objective and, therefore, helps the most as an activity is testing.

Testing is often performed with test cases. In case you aren’t familiar with the, test cases are basically the expected outcomes for specific situations when using some application; they may include a detailed description of what steps to follow in order to get to certain point where the actual testing takes place. This tool is very useful, if done correctly it could actually help with both parts of the V&V process.

Other tools for the verification part may include reviews, walkthroughs and inspections, and they all can have different levels of rigor depending on how serious or formal the V&V process is.

The main obstacle for many organizations is how overwhelming it can be for them to correctly perform a strict verification and validation process. In reality, V&V can be somewhat simplified to be better understood, and this site has come up with five general steps that may be follow to meet basic requirements and still achieve great quality. Obviously the process isn’t THAT simple, but these steps are only intended to serve as a basic guide to at least know what’s supposed to be done through the process:

1. Create the validation plan. Helps identify the responsibilities for each of the participants and defines what has to be achieved, what criteria has to be met, what tools are to be used, and other similar things.

2. Define system requirements. Define what the system is supposed to do and classify all of it depending on what is specified in each requirement: resources, users, security, etc.

3. Create a validation protocol and test specifications. Create all of the tests to be performed in the next step as complete and detailed as possible.

4. Testing. Testing (do I even have to explain?)

5. Develop/revise procedures and final report. A final validation report is produced, reviewed, and approved. Its approval means the system is ready to be released.

In case the previous steps weren’t exactly what you expected, there are more possible interpretations! For instance, this webpage also lists some steps that may help with the V&V process, but this one has ten and rather than stating the activities that should be performed, it describes what kind of document or protocol should be completed by the end of each one. I won’t list any of that in this entry, but I definitely recommend checking it out.

This is yet another way of improving your software products by following certain steps and protocols and all of that stuff. For me, this process in particular can be very helpful for some people since it aims to answer to very clear and simple questions. That may be more than enough to make developers understand what the actual goal is.

TL; DR: Verification and validation are different things.

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with
Get started
%d bloggers like this: