In Software Engineering, we chant the term of validation and verification a lot between the software team members. Actually, it is used across the software project phases and I think there is a misconception in understanding the two terminologies and when to use them.
The validation and verification are frequently used during the testing phase while as we will see that each SDLC phase will use these two terminologies somehow according to the phase context and the main involved role at each phase.
Before that, let us define these two terminologies:
Validation is the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification. Simply “Are we building the right system? Concerned with the customer”
Verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation. Simply “Are we building the system right? Concerned with the team for the customer”
I see that V&V are essential across SDLC phases, most of the articles across the internet discussed the V&V from the testing phase perspective. For example, that the validation process is done at the end of the development process during the delivery of the software product to the end customer, mainly at the user acceptance test (UAT). While I see that validation has a role during all the process not only during the testing and delivery.
So, let us take a look at how it is used in the SDLC phases:
| Phases | Validation | Verification |
| Requirements Elicitation | The analyst should validate the requirements with the customer to better understand them through different analysis techniques.
If the analyst considers the architect, designer, or the developers as a customer, he/she will validate also their understanding of these requirements to eliminate any ambiguity |
The analyst should verify that each requirement is unique and it has a purpose and origin, as well he/she verify that the requirements are doable, in scope, and testable.
This is done with other team members as well. |
| Architecture & Design | If the software has a UI, prototype, wireframe design, process design, …etc.
these types of designs should be validated with the customer and the analyst to ensure meeting the customers’ requirements and their expectations. |
The architect and software designer will verify that the software designs are meeting the non-functional requirements, for example, performance and usability.
On the other side, they may verify that the software design is not rigid but scalable to meet future needs. |
| Implementation (Coding) | During the implementation, the developers may find part of the requirements is not clear or incomplete, they may need to validate that with the customer.
Also, the requirements can be changed at any time, the analyst may need to validate the new changes and their effect on the other requirements. |
Similarly, during implementation and coding, the developers start doing unit and integration test for their code, and they may have peer review and static code analysis.
All of these are types of verification during the implementation phase. |
| Testing | The testing team should ensure that the software meets the business requirements and is fit for use by building the user acceptance test cases and validate it with the customers.
Moreover, ensuring that error messages, validation messages are clear. Most of the techniques used are related to the black box testing. The main concern here that the software is accepted by the customer and all requirements have been met. |
In this phase, testing and quality team should test the requirements and ensure that all test cases have been passed, all functionalities are working fine and there is enough and acceptable code coverage.
Also, they verify designs and non-functional requirements. Most of the techniques can be combined between white and black box testing. The main concern here that the software is the output of each function is working as expected |
| Deployment | Making sure that the software is working after installation and configuration.
All integrations are working with internal and external systems |
Auditing of installation and configuration of the environment, run smoke tests to ensure everything is working fine with each release.
Releasing the test report |
| Operational Support | Validating that the software operation is smooth. There are no logical errors or something is broken, evaluate the changes and new requirements.
Besides, operation inspection can help in validating this smooth operation and understanding new changes. |
Verify that the software is up without downtime, there are no data issues and logs are clear.
There is nothing broken in the integration. |
Why should you care about validation and verification as a software engineer?
Mainly, in most of the software project, I see that the software process considers building the software right more than building the right software, because of that most of the software projects fail! What does that mean?
Suppose that we can have a zero error software, but it is not workable. Why it is not working? Mainly, due to it is not aligned with user requirements, for example, you can have an input form, this form is verified at tested correctly and functionally while it does not contain all required input fields, or the designer or the developers decided to add extra input fields that were not required from the customer. Finally, the form is verified and functional while it is not validated.
In some of enhanced software development life cycles, for example, the iterative and agile models, the customer became more engaged with the process and the software team can have early feedback which is part of the validation process. In this regards, selection of the right SDLC is also affecting the end product of the software and its acceptance by the customer.
If you see that this article is useful, please make sure to share it with your friends. Leave your questions and suggestions in the comments section below and I’ll try to reply as soon as I can.
Help to do more!
The content you read is available for free. If you’ve liked any of the articles at this site, please take a second to help us write more and more articles based on real experiences and maintain them for you and others. Your support will make it possible for us.
$10.00
4 thoughts on “Validation and Verification in SDLC”