What does Verification and Validation mean?
Both concepts are crucial to mantain good software quality that complies with the standards we talked about before. But we have to understand what each concept means, and what are their differences before we dive deep into them. Let’s see their formal definitions according to the IEEE-STD-610:
Verification : “A test of a system to prove that it meets all its specified requirements at a particular stage of its development”.
Validation: “An activity that ensures that an end product stakeholder’s true needs and expectations are met.
With the above definitions, we can see that Verification is more about making sure we are building the software correctly with good practices, standards, and following a good methodology that allows it to meet the goals set at the start of the development cycle. Meanwhile Validation is more about making sure that the product being built is one that benefits the client, a product that ensures that the client’s needs are being met, because we may have a good product that works, but it may not solve the problems of our client.
When do we implement it into our SDLC?
The verification and validation process is one that should be present in each stage of the SDLC, we can’t allow errors, bugs, miscommunication to keep piling on until the end, because we may even find we have too many which may make the software completely useless since it would become much more expensive to fix. That’s why Verification and Validation must be done at each stage, to find errors on the planning phase, on the design phase, on the coding phase, on each process that the team does, to ensure that the errors never become too costly or difficult to fix, and also ensuring that the software being built is adequate for our client, that it is what our client needs.
Standards for V&V
The main standard used in the industry is the IEEE 1012-2016 which incorporates both verification and validation as a rigorous process carried since the beginning until the end.
The standard defines and talks about all the tests that should be done to comply with the standard, talking about tests like: System Integration, Acceptance Testing, Software Integration Testing, Component Testing and more.
The standard also talks about continuous review, how every test, every test result and every process done on V&V must be reviewed by the whole team working on the software to ensure of its quality and make recommendations for the next phase so the errors, or improvements that could be made are done. It should have a constant appeareance on each stage of the SDLC.
If you want to dive deeper into what the standard talk about you can visit the following website: https://katie.mtech.edu/classes/esof411/Schedule/IEEE_Standard_System_Software_HardwareV&V_160pages.pdf
How do I actually implement it into my SDLC?
Just as for the SDLC, you have to start with planning, make a good planning of the Verification and Validation process, one that covers fully the objectives, needs of the client and requirements of the software.
The IEEE-1012 standard suggests making a document stating the objectives that should be met by the Verification and Validation, what products are being covered, who is involved and on which role, the activites, processes, tasks and tests that will be done to verificate and validate and how will the report of results will be done. The main part of the document should be about the planning of tests and their design and the analysis that will be performed based on those tests.
As we see, the most important part are the tests for the V&V, they need to be built according to the goals of the software, but according to the IEEE standard, they should have the following types of test almost by default:
- Design Evaluation
- Interface Analysis
- Traceability Analysis
- Criticality Analysis
- Software Component Tests
- Software Integration Tests
- Software Qualification Tests
- Software Acceptance Tests
- Hazard Analysis
- Risk Analysis
- Security Analysis
All the above tests are required to test and analyze almost everything about the software, and with those we can be almost completely sure that we will achieve our goals. Each test is in the same level of importance, and some are even preventive to detect certain risks or menaces that although not present on the software on that moment, they may arise later.
After the design, testing and analysis is finished, a good report must be made, which will be reviewed by the whole software development team. The report should present documentation about how the tests were performed, the results observed from the tests and conclusions and recommendations that can be made from their results. This process is very important, tests aren’t useful if you don’t learn anything from them! The reviewing should reveal and offer good insights for the whole team to implement them and improve the software on the next stages of it. They should cause change towards a better direction.