Here you can find some descriptions, activities and cool information about software development and application.

SW Verification and Validation

In one of our previous post we have talked about software testing. There are many options totest your software, but now we have another topic related to discuss. Is software validation the same as software verification?

Validation can be described as verifying that you are building what the customer wants. Software validation is the process of ensuring that your application meets functional and non-functional requirements before coding and during development.

Verification if verifying that the product is being assembled correctly, after you have determined what you are supposed to build.

Keep in mind both concepts, the difference between validation and verification is functional. Validations is to cover all of the “requirements” of the user, and verification means “functionality” in all of thse parts.

For example, we have shown that software testing is performed in different layers, from Unit testing to Exploratory testing. In verification you guarantee that all of this parts really works appropiately before the project is “built”.

I personally read the 4.7, which I saw asone of the most important ones. Let me give you a little explanation of my thouhgs:

Think on what an application tells you there is an update available (yes an update instead on an upgrade), there are a lot of steps before developers launch this update, they needto be sure that the changes they have made to the source code have not impacted negatively to the general structure of the code and all of the software needs to be validated again, there are different methods just like a software test regression. This is to ensure your changes are not affecting any other part of the structure as we mentioned.

And yes, this can be misundertood with verification doesn´t it?

The difference is that the verification in this case of validation is a subprocess.

Once you have launched an update you need to verificate it. Then you validate it.

1. Include all stakeholders in the requirements definition phase.
2. Have a strict definition of the requirements definition phase. Do not let new requirements creep in once coding begins.
3. Determine where the data must come from and go as part of the typical use of the tool. If the data interface is frequently used, include the ability to transfer the data between those applications or databases a requirement and include the testing of these data transfers in software validation.
4. Focus software validation efforts on core functions over optional enhancements if crunched for time. For example, ensuring that the new brake designs work properly is more important than checking out the new sound system. If the new sound system doesn’t work, it’s only an annoyance. If the brakes fail, your customers won’t let you take them for another ride.
5. Recognize that functional applications are a requirement, not an enhancement.