Verification vs Validation

Verification ensures that the system (software, hardware and documentation) complies with an organization’s standards and processes, relying on review or non-executable methods.

Validation ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated. Verification answers the question, “Did we build the right system?” while validations addresses, “Did we build the system right?”

Examples for Verification and Validation

Verification requires several types of reviews, including requirement reviews, design reviews, code walkthroughs, code inspections, and test reviews.

The system user/end user should be involved in these reviews to find defects before they are built into the system. In the case of purchased systems, user input is needed to assure that the supplier makes the appropriate tests to eliminate defects.

The below list of points are examples for verification, it will show who performs the task and what are the deliverables for the Task.

Requirements Reviews:

Performed by: Developers, Users
Explanation: The Study and the discussion of the computer system requirements to ensure they meet stated user needs and are feasible
Deliverable: Reviewed statement of requirements, ready to be translated into system design.

Design Reviews:

Performed by: Developers
Explanation: The study and discussion of the computer system design to ensure it will support the system requirements.
Deliverable: System design, ready to be translated into computer programs, hardware configurations, documentation, and training.

Code Walkthroughs:
Performed by: Developers
Explanation: An informal analysis of the program source code to find defects and verify coding techniques
Deliverable: Computer software ready for testing or more detailed inspections by the developer.

Code Inspections:

Performed by: Developers
Explanation: A formal analysis of the program source code to find defects as defined by meeting computer system design specifications, performed by the team composed of developers and subject matter experts.
Deliverable: Computer software ready for testing by the developer.

Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your Computer had fixed the starter of your computer, you’d try to start the system). Examples of validation are explained below:

Unit Testing:

Performed by: Developers
Explanation: The testing of a single program, module, or unit of code. Usually performed by the developer of the unit and validates that the software performs as designed
Deliverable: Software unit ready for testing with other system components, such as other software units, hardware, documentation, or users.

Integrated Testing:

Performed by: Developers
Explanation: The testing of related programs, modules, or units of code and validates that multiple parts of the system interact according to the system design.
Deliverable: Portions of the system ready for testing with other portions of the system.

System Testing

Performed by: Developers, Users
Explanation: The testing of an entire computer system. This kind of testing can include functional and structural testing, such as stress testing and validates the system requirements.
Deliverable: A tested computer system, based on what was specified to be developed or purchased.

User Acceptance Testing

Performed by: Users
Explanation: The testing of a computer system or parts of a computer system to make sure it will work in the system regardless of what the system requirements indicate.
Deliverable: A tested computer system, based on user needs.

Determining when to perform verification and validation relates to the development, acquisition, and maintenance of software. For software testing, this relationship is especially critical because:

The corrections will probably be made using the same process for developing the software. If the software was developed internally using a waterfall methodology, that methodology will probably be followed in making the corrections on the other hand, if the software was purchased or contracted, the supplier will likely make the correction. You’ll need to prepare tests for either eventuality.

Testers can probably use the same test plans and test data prepared for testing the original software. If testers prepared effective test plans and created extensive test data, those plans and test data can probably be used in the testing effort, thereby reducing the time and cost of testing.

Software Testing: 

Add new comment