March 16th, 2022
The Differences Between Verification and Validation With Software
Software verification and validation both involve analyzing software in order to determine whether it meets stated specifications, fulfills its required purpose, and works as intended. Both verification and validation are very similar terms, but they refer to different aspects of software analysis. In this article, both software verification and validation will be covered, along with the differences between them.
What is software verification?
Software verification refers to verifying that a piece of software fulfills expectations as laid out in formal specifications, design documents, and client requirements. The main goal of the verification process is to check that the software as built works as it is intended and matches the stated goals and outcomes.
Verification generally precedes validation. That means that software is first verified: it is checked to ensure that it is built as it is intended to be before it is then validated. This is because there is no point checking out whether the specific implementation built works if it doesn’t conform to the product specifications. The client must be happy that you’ve built the correct feature before checking if you built the feature correctly.
Verification is typically a manual process, involving inspections, reviews and walkthroughs with developers, project managers, and other key personnel. It involves cross-referencing and comparing the intentions and stated requirements of the software with how it actually works. It is not so much concerned with the specific implementation of features, so much as the presence of them and whether they achieve the goals as laid out in the project specifications.
What is software validation?
Software validation refers to the process of validating that a piece of software works without any bugs, mistakes or other types of malfunctions. This involves testing the functionality of the software to make sure that the actual implementation of the software works as intended.
Software validation can be thought of as less concerned about why a feature has been built in a particular way and more that it works in the way that it was built. So, for example, a website that involves selling alcohol will probably have an age check associated with it. Software validation is concerned with questions such as, “does an underage user get rejected?”, “does it properly calculate the age of a visitor from their date of birth?” and, “what happens to users born on leap years?” Why the age check is there is beyond the scope of validation. The fact that it is a legal requirement for the age check to be there would be part of the verification process rather than validation.
Software validation involves testing the code directly and can largely be automated. Validation is generally what is thought of when one thinks of software testing – things like unit tests, integration tests, and user acceptance testing are all examples of software validation. Tests are written and run against the codebase to check whether the correct outputs are returned for the corresponding inputs. This is why software verification comes first, as verification is needed to determine what the correct outputs should be.
What are the main differences between validation and verification?
Software verification can be thought of in terms of why software behaves as it does and validation can be thought of as analyzing how it behaves. As you may imagine, there is a lot of overlap between the two. The difference between the two can be boiled down to asking two slightly different questions. Validation asks the question, “does the software we have built work as we expect it to?”, whereas verification asks, “did we build what we intended to?”
To give a concrete example, imagine performing software verification and validation of an e-commerce system. First, the e-commerce platform would be subject to verification. This will ask questions such as does it have all the features laid out in the design and specification documents? For an e-commerce platform, this would mean things like checking that a visitor has the ability to add products to their cart and checkout, making sure it is compatible with other tools like email marketing and customer tracking, and that all requested features are in place.
This is usually broken down into high and low-level requirements. High-level requirements look at the broad picture of how a system is architected and how well the implementation matches up to the specification. This then may be followed with more low-level design documents and feature-specific verification that looks more at individual features within the software to ensure specification compliance.
Software validation is then used to test these features. Unit tests and integration tests can be run to check that products are added to the cart appropriately, external APIs are integrated correctly, and that there are no runtime errors or other code-based malfunctions that prevent the software from working as intended.
What type of systems require validation and verification?
Generally speaking, every software project should go through both software verification and validation. There are few exceptions to this, as almost all projects will need to be inspected to determine whether they meet project specifications and function as intended.
Software verification is generally more difficult to conduct. This is because it can be less obvious whether a project meets specifications or not. For example, a piece of software may not meet the formal software architecture specifications while still functioning as expected. Thus, it is more difficult to determine proper software verification than validation. Good software verification relies on having good technical specifications. Writing practical technical specifications is not easy, but fortunately there are many guides available online to help with this.
What’s important is to make sure that all appropriate stakeholders are involved in the process where possible. Keeping product specification development between management and the client without involving developers at all is a common problem that can result in low-quality technical specs and confusing product requirements. Likewise, only involving developers and managers, without extensively consulting the client, can result in creating software that works well but doesn’t do what the client wants. None of these situations is ideal, so the more input you can get from as many important stakeholders as possible will help you to develop high-quality tech and project specifications.
Examples of verification and validation
There are many different types of both software verification and validation methods and techniques. Some examples have already been given throughout the article, but to reduce an example to its fundamental essence, once again let us imagine a new e-commerce project is going through verification and validation.
In the project requirements, it is stated that there must be a large buy button on every product page. This buy button should include a shopping cart icon and, when the button is clicked, have the product added to the user’s cart and redirect them to checkout.
Firstly, the software must be verified. This means checking for the presence of a buy button on the product page and making sure it meets the project requirements. In this case, it means checking that it has a shopping cart icon. If the button instead says “purchase”, then this would fail verification and it would need to be changed until it meets the project requirements.
Once the button has passed verification, it is then subjected to validation testing. This tests whether the button works as intended when a user clicks on it. Does it add a product to the cart? Is it the correct product? Does it then redirect the user to the checkout? If the button does nothing when clicked on or adds a completely different product to the cart, then this would fail validation and would need changing.
Final Thoughts
Software verification and validation are both important parts of the overall software testing and quality assurance processes. Verification checks that you have built what the client wants and validation checks that it works as expected. Both are integral to building high-quality, functional software, no matter the industry or project.
Good software verification and validation involves having an appropriate testing strategy. If you don’t know how to write good quality specifications or how to write good tests to run against those specifications, then get in touch with our team at Guide Rails. Our team of experts can help walk you through the steps involved in order to create high-quality software verification and validation processes to ensure that the software you create works exactly as expected and meets all your client’s demands.