Software Verification and Validation Key Differences and Process

In the realms of software project management, testing, and engineering, verification and validation (V&V) is the critical process of ensuring that a software system meets its specifications and requirements to fulfill its intended purpose. Often referred to as software quality control, this process is typically the responsibility of software testers as part of the software development lifecycle (SDLC).

Definitions Verification vs. Validation

While often confused, verification and validation are distinct concepts. Barry Boehm succinctly expressed the difference as follows:

• Verification: Are we building the product right?
• Validation: Are we building the right product?

"Building the product right" focuses on whether the specifications are correctly implemented by the system, while "building the right product" ensures that the software meets the actual needs of the users and stakeholders.

Software Verification

Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. It involves checking if the software achieves its goals without bugs or gaps, assuming the specifications are correct.

Artifact or Specification Verification

Verification is not solely about running the software; it is often performed by reviewing associated artifacts. The output of each software development process stage can be verified against its input specification. Examples include:

• Design Specification Verification: Checking if the architectural design, detailed design, and database logical model specifications correctly implement the functional and non-functional requirements.
• Construction Artifact Verification: Ensuring that the source code, user interfaces, and database physical model correctly implement the design specification.

Software Validation

Software validation is the high-level checking process that ensures the software product satisfies its intended use and meets the needs of all stakeholders, including users, operators, administrators, and investors.

Internal and External Validation

Validation can be performed in two ways:

• Internal Validation: This assumes that the stakeholder goals were correctly understood and expressed in the requirement artifacts. If the software meets the requirement specification, it is internally validated.
• External Validation: This occurs when stakeholders are asked directly if the software meets their needs. This can be a discrete event or a continuous process depending on the development methodology. Successful final external validation typically requires an acceptance test, which is a dynamic test.

Artifact or Specification Validation

Requirements should be validated before the software product is fully ready. Examples include:

• User Requirements Specification Validation: Validating the User Requirements Specification (URS) by interviewing stakeholders or releasing prototypes for assessment.
• User Input Validation: Checking if the input provided by users meets domain rules and constraints, such as data type, range, and format.

  Summary of Validation vs. Verification

  Feature	Verification	Validation
  Question	Are we building the product right?	Are we building the right product?
  Focus		Specifications and artifacts	User needs and stakeholder goals
  Method	Static testing (reviews, walkthroughs)	Dynamic testing (running the software)