SOFTWARE TESTING VERIFICATION

VALIDATION AND QUALITY ASSURENCE

Assignment:
Verification Process

Submitted By:
Sushil Timilsina
Roll: se201147

Submission Date:
17th may, 2015

Software Verification:
Software verification is act of reviewing, inspecting, testing, checking, auditing or
otherwise establishing and documenting whether items, processes, services or
documents conform to specified requirements. It can also be taken as 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 the phase.

Software Review:
After the work product is developed, the Project Leader calls for a Review. The work
product is distributed to the personnel who involves in the review. The main audience
for the review should be the Project Manager, Project Leader and the Producer of the
work product. There are three type of reviews. They are described as below.

1. In Process Reviews
In-Process Review looks at the product during a specific time period of a life
cycle. They are usually limited to a segment of a project, with the goal of
identifying defects as work progresses, rather than at the close of a phase or
even later, when they are more costly to correct.
2. Phase-End Review
This review looks at the product for the main purpose of determining whether to
continue with planned activities. They are held at the end of each phase, in a
semiformal or formal way. Defects found are tracked through resolution
3. Post Implementation Review
These reviews are held after implementation is complete to audit the process
based on actual results. They are held to assess the success of the overall
process after release and identify any opportunities for process improvement.
They can be held up to three to six months after implementation, and are
conducted in a format.

Classes of Reviews in Software Verification Process.

1. Peer Review (Informal)

Peer Review is generally a one-to-one meeting between the author of a work
product and a peer, initiated as a request for import regarding a particular artifact
or problem. There is no agenda, and results are not formally reported. These
reviews occur on an as needed basis throughout each phase of a project.
2. Walk-Through (Semiformal)
The author of the material being reviewed facilitates walk-Through. The
participants are led through the material in one of two formats; the presentation is
made without interruptions and comments are made at the end, or comments are
made throughout. In either case, the issues raised are captured and published in
a report distributed to the participants. Possible solutions for uncovered defects
are not discussed during the review. The objective of a walkthrough is to
evaluate a specific software element (e.g. document, source module). A
walkthrough should attempt to identify defects and consider possible solutions. In
contrast with other forms of review, secondary objectives are to educate, and to
resolve stylistic problems.
The walkthrough process is carried out by a walkthrough team, which is made up
of:
a leader
a secretary
the author (or authors)
Members.
The leader, helped by the secretary, is responsible for management tasks
associated with the walkthrough. The specific responsibilities of the leader
include:
nominating the walkthrough team;
Organizing the walkthrough and informing all participants of the
date, place and agenda of walkthrough meetings.
distribution of the review items to all participants before
walkthrough meetings;
organizing as necessary the work of the walkthrough team;
Chairing the walkthrough meeting.
Issuing the walkthrough report.

The author is responsible for the production of the review items, and for
presenting them at the walkthrough meeting. Members examine review items,
report errors and recommend solutions.
3. Inspection (Formal)
A knowledgeable individual called a moderator, who is not a member of the team
or the author of the product under review, facilitates inspections. A recorder who
records the defects found and actions assigned assists the moderator. The
meeting is planned in advance and material is distributed to all the participants
and the participants are expected to attend the meeting well prepared. The
issues raised during the meeting are documented and circulated among the
members present and the management. The objective of inspection is to identify
problems, not to correct them.

4. Audit

Audits are independent reviews that assess compliance with software

requirements, specifications, baselines, standards, procedures, instructions,
codes and contractual and licensing requirements. To ensure their objectivity,
audits should be carried out by people independent of the development team.
The audited organization should make resources (e.g. development team
members, office space) available to support the audit.
A 'physical audit' checks that all items identified as part of the configuration are
present in the product baseline. A 'functional audit' checks that unit, integration
and system tests have been carried out and records their success or failure.
Other types of audits may examine any part of the software development
process, and take their name from the part of the process being examined, e.g. a
'code audit' checks code against coding standards.
The objective of an audit is to verify that software products and processes
comply with standards, guidelines, specifications and procedures.
The audit process is carried out by an audit team, which is made up of:
a leader
members
The leader is responsible for administrative tasks associated with the audit. The
specific responsibilities of the leader include:
nominating the audit team;

organizing the audit and informing all participants of the

schedule of activities;
issuing the audit report.

Members interview the development team, examine review items, report errors
and recommend solutions.