Software Verification and Validation With Simple Examples
It is important to note that verification and validation are not mutually exclusive. In fact, they are complementary processes. Find out more in this article.
Join the DZone community and get the full member experience.Join For Free
Verification and validation are two distinct processes often used in various fields, including software development, engineering, and manufacturing. They are both used to ensure that the software meets its intended purpose, but they do so in different ways.
Verification is the process of checking whether the software meets its specifications. It answers the question: "Are we building the product right?" This means checking that the software does what it is supposed to do, according to the requirements that were defined at the start of the project. Verification is typically done by static testing, which means that the software is not actually executed. Instead, the code is reviewed, inspected, or walked through to ensure that it meets the specifications.
Validation is the process of checking whether the software meets the needs of its users. It answers the question: "Are we building the right product?" This means checking that the software is actually useful and meets the expectations of the people who will be using it. Validation is typically done by dynamic testing, which means that the software is actually executed and tested with real data.
Here are some typical examples of verification and validation:
- Verification: Checking the code of a software program to make sure that it follows the correct syntax and that all of the functions are implemented correctly
- Validation: Testing a software program with real data to make sure that it produces the correct results
- Verification: Reviewing the design documents for a software system to make sure that they are complete and accurate
- Validation: Conducting user acceptance testing (UAT) to make sure that a software system meets the needs of its users
When To Use
Conventionally, verification should be done early in the software development process, while validation should be done later. This is because verification can help to identify and fix errors early on, which can save time and money in the long run. Validation is also important, but it can be done after the software is mostly complete since it involves real-world testing and feedback.
Another approach would be to start verification and validation as early as possible and iterate. Small, incremental verification steps can be followed by validation whenever possible. Such iterations between verification and validation can be used throughout the development phase. The reasoning behind this approach is that both verification and validation may help to identify and fix errors early.
Weather Forecasting App
Imagine a team of software engineers developing a weather forecasting app. They have a specification that states, "The app should display the current temperature and a 5-day weather forecast accurately." During the testing phase, they meticulously review the code, check the algorithms, and ensure that the app indeed displays the temperature and forecast data correctly according to their specifications. If everything aligns with the specification, the app passes verification because it meets the specified criteria.
Now, let's shift our focus to the users of this weather app. They download the app, start using it, and provide feedback. Some users report that while the temperature and forecasts are accurate, they find the user interface confusing and difficult to navigate. Others suggest that the app should provide more detailed hourly forecasts. This feedback pertains to the user experience and user satisfaction, rather than specific technical specifications.
Verification confirms that the app meets the technical requirements related to temperature and forecast accuracy, but validation uncovers issues with the user interface and user needs. The app may pass verification but fail validation because it doesn't fully satisfy the true needs and expectations of its users. This highlights that validation focuses on whether the product meets the actual needs and expectations of the users, which may not always align with the initial technical specifications.
Social Media App
Let's say you are developing a new social media app. The verification process would involve ensuring that the app meets the specified requirements, such as the ability to create and share posts, send messages, and add friends. This could be done by reviewing the app's code, testing its features, and comparing it to the requirements document.
The validation process would involve ensuring that the app meets the needs of the users. This could be done by conducting user interviews, surveys, and usability testing. For example, you might ask users how they would like to be able to share posts, or what features they would like to see added to the app.
In this example, verification would ensure that the app is technically sound, while validation would ensure that it is user-friendly and meets the needs of the users.
Online Payment Processing App
A team of software engineers is developing an online payment processing app. For verification, they would verify that the code for processing payments, calculating transaction fees, and handling currency conversions has been correctly implemented according to the app's design specifications. They would also ensure that the app adheres to industry security standards, such as the Payment Card Industry Data Security Standard (PCI DSS), by verifying that encryption protocols, access controls, and authentication mechanisms are correctly integrated. They would also confirm that the user interface functions as intended, including verifying that the payment forms collect necessary information and that error messages are displayed appropriately.
To validate the online payment processing software, they would use it in actual payment transactions. One case would be to process real payment transactions to confirm that the software can handle various types of payments, including credit cards, digital wallets, and international transactions, without errors. Another case would be to evaluate the user experience, checking if users can easily navigate the app, make payments, and receive confirmation without issues.
Predicting Brain Activity Using fMRI
A neuroinformatics software app is developed to predict brain activity based on functional magnetic resonance imaging (fMRI) data. Verification would verify that the algorithms used for preprocessing fMRI data, such as noise removal and motion correction, are correctly translated into code. You would also ensure that the user interface functions as specified, and that data input and output formats adhere to the defined standards, such as the Brain Imaging Data Structure (BIDS).
Validation would compare the predicted brain activity patterns generated by the software to the actual brain activity observed in the fMRI scans. Additionally, you might compare the software's predictions to results obtained using established methods or ground truth data to evaluate its accuracy. Validation in this context ensures that the software not only runs without internal errors (as verified) but also that it reliably and accurately performs its primary function of predicting brain activity based on fMRI data. This step helps determine if the software can be trusted for scientific or clinical purposes.
Predicting the Secondary Structure of RNA Molecules
Imagine you are a bioinformatician working on a software tool that predicts the secondary structure of RNA molecules. Your software takes an RNA sequence as input and predicts the most likely folding pattern. For verification, you want to verify that your RNA secondary structure prediction software calculates free energy values accurately using the algorithms described in the scientific literature. You compare the software's implementation against the published algorithms and validate that the code follows the expected mathematical procedures precisely.
In this context, verification ensures that your software performs the intended computations correctly and follows the algorithmic logic accurately.
To validate your RNA secondary structure prediction software, you would run it on a diverse set of real-world RNA sequences with known secondary structures. You would then compare the software's predictions against experimental data or other trusted reference tools to check if it provides biologically meaningful results and if its accuracy is sufficient for its intended purpose.
The Light Switch in a Conference Room
Consider a light switch in a conference room. Verification asks whether the lighting meets the requirements. The requirements might state that "the lights in front of the projector screen can be controlled independently of the other lights in the room." If the requirements are written down and the lights cannot be controlled independently, then the lighting fails verification. This is because the implementation does not meet the requirements.
Validation asks whether the users are satisfied with the lighting. This is a more subjective question, and it is not always easy to measure satisfaction with a single metric. For example, even if the lights can be controlled independently, the users may still be dissatisfied if the lights are too bright or too dim.
Verification is usually a more technical activity that uses knowledge about software artifacts, requirements, and specifications. Validation usually depends on domain knowledge, that is, knowledge of the application for which the software is written. For example, validation of medical device software requires knowledge from healthcare professionals, clinicians, and patients.
It is important to note that verification and validation are not mutually exclusive. In fact, they are complementary processes. Verification ensures that the software is built correctly, while validation ensures that the software is useful. By combining verification and validation, we can be more confident that our product will make customers happy.
Opinions expressed by DZone contributors are their own.