As always, let’s get to what we’re gonna be talking about in this post first:

1. V&V in the life cycle of software development
2. International standards for V&V of Software
3. Planning V&V
4. Administration of a V&V Plan

Before everything, we shall ask our main questions.

What is verification and validation?

Just by hearing those two words, we can get a pretty basic definition, which would be verification: checking that something completes all the requirements it needs and validation: the process that we follow to verificate a product, thing or whatever you could think.

When talking about the life cycle in software, validation and verification is a step used during almost the whole process of development, so we’ll see in the following table what happens in each one, very briefly:

Phases	Validation	Verification
Requirements	Validate requirements along with the client to ensure proper understanding of what’s going to be done.	Verifying that all requierements are unique and doable.
Architecture and Design	All types of design that might end up being used have to be validated with the costumer, as to meet their expectations.	We verify that all designs are meeting the non-functional requirements (like performance or usability)
Implementation	For each requirement done, we have to validate with the client if that’s what they wanted.	When doing unit and integration tests, or while having peer review.
Testing	Check that all functionality meets the client expectations and that all messages are clear.	All test cases need to pass this part, as to ensure that everything is working as intended.
Deployment	All software after installation should be working as intented.	Configuring environment and running smoke tests.

As to international standards, ISO has always been there to mantain a certain level needed for validating different things, including software. As to what I could say about this, is simply that by having a certain level required for stuff to be valid and verified by certain organisms, we can mantain a same procedure for developing new stuff, such as software, I’ll also leave this article here so that people can indulge in really technical stuff if they feel like it, because I dont feel like it.

https://dqs-cfs.com/2019/10/verification-and-validation-why-the-new-standard-iso-iec-17029-matters/

Planning and administrating V&V, the real challenge

For this, we have a term that already exists and depicts pretty well what was to be done. Verification and Validations Plans. This pretty much works by going hand with hand on your normal software life cycle, but implementing everything that’s needed to make a V&V correctly:

• Explaining the test and objective of the project.
• Define what items you’re gonna be testing, using the required documentation.
• What features need to be tested? Along with all the data you’ll need.
• What DOESN’T need to be tested? This should be a small list, and you can include items that need too much time and effort to be properly tested at earlier phases.
• How is your testing team gonna approach the requirements? By defining a pass/fail criteria, you can prevent later confusion on how to validate and verificate diverse stuff.
• An approach for handling any mistakes and errors that could stop your testing, otherwise you’ll lose time on making all test cases needed, with their design specification and procedures.
• Environmental needs (I think this one pretty much speaks for itself? Please don’t run some software on a all mighty computer that your client does NOT have).
• Approval from the client for all requirements.
• Operation and maintenance in case a step was missed or something went wrong.
• An open space of possible upgrades or replacement.

So, this was it for Validation and Verification, if you have anything to share, like experiences, knowledge on the topic, or just a plain comment on how you dislike my blog, please share in the comments so that other people can also enjoy a different perspective!