Topic: Verification And Validation

<>.fullpost{display:inline;}<>.fullpost{display:inline;}

Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. It is actual testing of the application.

1. Am I building the right product.

2. Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.

3. Am I accessing the right data (in terms of the data required to satisfy the requirement).

4. High level activity.

5. Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment.

6. Determination of correctness of the final software product by a development project with respect to the user needs and requirements.


Verification: The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase.

Verification process helps in detecting defects early, and preventing their leakage downstream. Thus, the higher cost of later detection and rework is eliminated. It includes:

1. Am I building the product right.

2. The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and performs the selected functions in the correct manner.

3. Am I accessing the data right (in the right place; in the right way).

4. Low level activity.

5. Performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards.

6. Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle.


Review: A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. The main goal of reviews is to find defects. Reviews are a good compliment to testing to help assure quality. A few purposes’ of SQA reviews can be as follows:

Assure the quality of deliverable’s before the project moves to the next stage.
Once a deliverable has been reviewed, revised as required, and approved, it can be used as a basis for the next stage in the life cycle.

Various types of reviews:

Management Reviews: Management reviews are performed by those directly responsible for the system in order to monitor progress, determine status of plans and schedules, confirm requirements and their system allocation. Therefore the main objectives of Management Reviews can be categorized as follows:

- Validate from a management perspective that the project is making progress according to the project plan.

- Ensure that deliverables are ready for management approvals.

- Resolve issues that require management’s attention.

- Identify any project bottlenecks.

- Keeping project in Control.

Requirement Review: A process or meeting during which the requirements for a system, hardware item, or software item are presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include system requirements review, software requirements review. Product management leads Requirement Review. Members from every affected department participates in the review.

Input Criteria: Software requirement specification is the essential document for the review. A checklist can be used for the review.

Exit Criteria: Exit criteria include the filled & completed checklist with the reviewers’ comments & suggestions and the re-verification whether they are incorporated in the documents.

Design Review: A process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include critical design review, preliminary design review, and system design review.


Inspection: A static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Types include code inspection; design inspection, Architectural inspections, Test ware inspections etc. The participants in Inspections assume one or more of the following roles:

- Inspection leader
- Recorder
- Reader
- Author
- Inspector

All participants in the review are inspectors. The author shall not act as inspection leader and should not act as reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role.

Individuals holding management positions over any member of the inspection team shall not participate in the inspection.

Input to the inspection shall include the following:

- A statement of objectives for the inspection
- The software product to be inspected
- Documented inspection procedure
- Inspection reporting forms
- Current anomalies or issues list

Input to the inspection may also include the following:

- Inspection checklists: Any regulations, standards, guidelines, plans, and procedures against which the software product is to be inspected.

- Hardware product specifications

- Hardware performance data

- Anomaly categories

The individuals may make additional reference material available responsible for the software product when requested by the inspection leader.

The purpose of the exit criteria is to bring an unambiguous closure to the inspection meeting. The exit decision shall determine if the software product meets the inspection exit criteria and shall prescribe any appropriate rework and verification. Specifically, the inspection team shall identify the software product disposition as one of the following:

Accept with no or minor rework: The software product is accepted as is or with only minor rework. (For example, that would require no further verification).

Accept with rework verification: The software product is to be accepted after the inspection leader or a designated member of the inspection team (other than the author) verifies rework.

Re-inspect: Schedule a re-inspection to verify rework. At a minimum, a re-inspection shall examine the software product areas changed to resolve anomalies identified in the last inspection, as well as side effects of those changes.