In software project management, software testing, and software engineering, verification and validation is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"
Definitions Verification and validation are not the same thing, although they are often confused. Boehm succinctly expressed the difference as:
Verification: Are we building the product right? Validation: Are we building the right product? "Building the product right" checks that the specifications are correctly implemented by the system while "building the right product" refers back to the user's needs. In some contexts, it is required to have written requirements for both as well as formal procedures or protocols for determining compliance. Ideally, formal methods provide a mathematical guarantee that software meets its specifications. Building the product right implies the use of the Requirements Specification as input for the next phase of the development process, the design process, the output of which is the Design Specification. Then, it also implies the use of the Design Specification to feed the construction process. Every time the output of a process correctly implements its input specification, the software product is one step closer to final verification. If the output of a process is incorrect, the developers have not correctly implemented some component of that process. This kind of verification is called "artifact or specification verification".
Software verification
It would imply to verify if the specifications are met by running the software, but this is not possible (e.g., how can anyone know if the architecture/design/etc. are correctly implemented by running the software?). Only by reviewing its associated artifacts, can someone conclude whether or not the specifications are met.
Artifact or specification verification The output of each software development process stage can also be subject to verification when checked against its input specification (see the definition by CMMI below). Examples of artifact verification:
Of the design specification against the requirement specification: Do the architectural design, detailed design and database logical model specifications correctly implement the functional and non-functional requirements specifications? Of the construction artifacts against the design specification: Do the source code, user interfaces and database physical model correctly implement the design specification?
Software validation Software validation checks that the software product satisfies or fits the intended use (high-level checking), i.e., the software meets the user requirements, not as specification artifacts or as needs of those who will operate the software only; but, as the needs of all the stakeholders (such as users, operators, administrators, managers, investors, etc.). There are two ways to perform software validation: internal and external. During internal software validation, it is assumed that the goals of the stakeholders were correctly understood and that they were expressed in the requirement artifacts precisely and comprehensively. If the software meets the requirement specification, it has been internally validated. External validation happens when it is performed by asking the stakeholders if the software meets their needs. Different software development methodologies call for different levels of user and stakeholder involvement and feedback; so, external validation can be a discrete or a continuous event. Successful final external validation occurs when all the stakeholders accept the software product and express that it satisfies their needs. Such final external validation requires the use of an acceptance test which is a dynamic test. However, it is also possible to perform internal static tests to find out if the software meets the requirements specification but that falls into the scope of static verification because the software is not running.
Artifact or specification validation Requirements should be validated before the software product as a whole is ready (the waterfall development process requires them to be perfectly defined before design starts; but iterative development processes do not require this to be so and allow their continual improvement). Examples of artifact validation:
User Requirements Specification validation: User requirements as stated in a document called User Requirements Specification are validated by checking if they indeed represent the will and goals of the stakeholders. This can be done by interviewing the stakeholders and asking them directly (static testing) or even by releasing prototypes and having the users and stakeholders to assess them (dynamic testing). User input validation: User input (gathered by any peripheral such as a keyboard, bio-metric sensor, etc.) is validated by checking if the input provided by the software operators or users meets the domain rules and constraints (such as data type, range, and format).
Validation vs. verification According to the Capability Maturity Model (CMMI-SW v1.1),
… excerpt ends here. Continue reading the full article.
