Sample SVVP
The various aspects of
SVVP are described in the following paragraphs.
1. Style. The SVVP should be plain and concise. The
document should be clear, consistent and modifiable. Authors should assume
familiarity with the purpose of the software, and not repeat information that
is explained in other documents.
2. Responsibility. The developer is normally responsible for the
production of the SVVP. The user may take responsibility for producing the
Acceptance Test Specification (SVVP/AT), especially when the software is to be
embedded in a larger system. It is however recommended that user member should
be part of team responsible for preparing SVVP.
3. Medium. It is usually assumed that
the SVVP is a paper document. The SVVP could be distributed electronically to
participants with the necessary equipment.
4. Service Information.
The
SR, AD, DD, UT, IT, ST and AT sections of the SVVP are produced at different
times in a software project. Each section should be kept separately under
configuration control and contain the following service information.
(a) Abstract
(b) Table of Contents
(c) Document Status Sheet
(d) Document
Change records made since last issue
5. Content of SVVP/SR, SVVP/AD &
SVVP/DD sections. These
sections define the review and tracing activities in the SR, AD and DD phases
of the lifecycle. While the project management plan(PMP) may summarise these
activities, the SVVP should provide the detailed information. For example the
PMP may schedule an AD/R, but this section of the SVVP defines the activities
for the whole AD phase review process. These sections of the SVVP should avoid
repeating material from the standards and guidelines and instead define how the
procedures will be applied.
(a) Purpose
(b) Reference Documents
(c) Definitions
(d) Verification overview
6. Content of SVVP/SR, SVVP/AD &
SVVP/DD sections. These
sections define the review and tracing activities in the SR, AD and DD phases
of the lifecycle. While the project management plan(PMP) may summarise these
activities, the SVVP should provide the detailed information. For example the
PMP may schedule an AD/R, but this section of the SVVP defines the activities
for the whole AD phase review process. These sections of the SVVP should avoid
repeating material from the standards and guidelines and instead define how the
procedures will be applied.
(a) Purpose
(b) Reference Documents
(c) Definitions
(d) Verification overview
(i) Organisation
(ii) Master
schedule
(iii) Resources
summary
(iv) Responsibilities
(v) Tools,
techniques and methods
(e) Verification Administrative Procedures
(i) Anomaly reporting and resolution
(ii) Task iteration policy
(iii) Deviation policy
(iv) Control procedures
(v) Standards, practices and conventions
(f) Verification Activities
(i) Tracing
(ii) Formal proofs
(iii) Reviews
(g) Software
Verification Reporting.
7. The description of the contents in detail
is given at Enclosure 7. Additional material should be inserted in additional
appendices. If there is no material for a section then the phrase 'Not
Applicable' should be inserted and the section numbering preserved.
8. Content
of SVVP/UT, SVVP/IT, SVVP/ST & SVVP/AT sections. The SVVP contains four sections
dedicated to each test development phase. These sections are called:
(a) Unit Test Specification (SVVP/UT);
(b) Integration Test Specification (SVVP/IT);
(c) System Test Specification (SVVP/ST);
(d) Acceptance Test Specification (SVVP/AT).
9. This directive recommends the following
table of contents for each test section of the SVVP. The description of the
contents in detail is given at Enclosure 8.
(a) Test Plan.
(i) Introduction
(ii) Test items
(iii) Features to be tested
(iv) Features not to be tested
(v) Approach
(vi) Item pass/fail criteria
(vii) Suspension criteria and resumption
requirements
(viii) Test deliverables
(ix) Testing tasks
(x) Environmental needs
(xi) Responsibilities
(xii) Staffing and training needs
(xiii) Schedule
(xiv) Risks and contingencies
(xv) Approvals.
(b) Test Designs (for each test
design...).
(i) Test design identifier.
(ii) Features to be tested.
(iii) Approach refinements.
(iv) Test case identification.
(v) Feature pass/fail criteria.
(c) Test Case Specifications (for each
test case...).
(i) Test case identifier
(ii) Test items
(iii) Input specifications
(iv) Output specifications
(v) Environmental needs
(vi) Special procedural requirements
(vii) Inter-case dependencies.
(d) Test Procedures (for each test
case...).
(i) Test procedure identifier
(ii) Purpose
(iii) Special requirements
(iv) Procedure steps.
(e) Test Reports (for each execution of a
test procedure ...).
(i) Test report identifier
(ii) Description
(iii) Activity and event entries.
10. Plan Evolution.
(a) UR phase.
(i) By the end of the UR review, the SR
phase section of the SVVP must be produced. The SVVP/SR must define how to
trace user requirements to software requirements so that each software
requirement can be justified. It should describe how the SRD is to be evaluated
by defining the review procedures. The SVVP/SR may include specifications of
the tests to be done with prototypes.
(ii) The initiator(s) of the user
requirements should lay down the principles upon which the acceptance tests
should be based. The developer must construct an acceptance test plan in the UR
phase and document it in the SVVP (SVV11). This plan should define the scope,
approach, resources and schedule of acceptance testing activities.
(b) SR phase.
(i) During the SR phase, the AD phase
section of the SVVP must be produced (SVVP/AD). The SVVP/AD must define how to
trace software requirements to components, so that each software component can
be justified. It should describe how the ADD is to be evaluated by defining the
review procedures. The SVVP/AD may include specifications of the tests to be
done with prototypes.
(ii) During the SR Phase, the developer
analyses the user requirements and may insert 'acceptance testing requirements'
in the SRD. These requirements constrain the design of the acceptance tests.
This must be recognised in the statement of the purpose and scope of the
acceptance tests.
(iii) The planning of the system tests should
proceed in parallel with the definition of the software requirements. The
developer may identify 'verification requirements' for the software. These are
additional constraints on the unit, integration and system testing activities.
These requirements are also stated in the SRD.
(iv) The developer must construct a system
test plan in the SR phase and document it in the SVVP. This plan should define
the scope, approach, resources and schedule of system testing activities.
(c) AD phase.
(i) During the AD phase, the DD phase
section of the SVVP must be produced (SVVP/DD). The SVVP/AD must describe how
the DDD and code are to be evaluated by defining the review and traceability
procedures.
(ii) The developer must construct an
integration test plan in the AD phase and document it in the SVVP. This plan
should describe the scope, approach, resources and schedule of intended
integration tests. Note that the items to be integrated are the software
components described in the ADD.
(d) DD phase.
(i) In the DD phase, the SVVP sections on
testing are developed as the detailed design and implementation information
become available.
(ii) The developer must construct a unit test
plan in the DD phase and document it in the SVVP. This plan should describe the
scope, approach, resources and schedule of the intended unit tests.
(iii) The test items are the software
components described in the DDD. The unit, integration, system and acceptance
test designs must be described in the SVVP. These should specify the details of
the test approach for a software feature, or combination of software features,
and identify the associated test cases and test procedures.
(iv) The unit integration, system and
acceptance test cases must be described in the SVVP. These should specify the
inputs, predicted results and execution conditions for a test case.
(v) The unit, integration, system and
acceptance test procedures must be described in the SVVP. These should provide
a step-by-step description of how to carry out each test case.
(vi) The unit, integration, system and
acceptance test reports must be contained in the SVVP.
11. Planning
of extensive and careful verification and validation is as important activity
as planning for development of software application. Evolution, documentation
and adoption of sound SVVP is very essential to ensure reliable and efficient
end software product.
12. It is very important to
prepare a sound plan for software verification and validation well in time. The
preparation of plan shall commence with the very first stage of software
development cycle (URD phase). All software verification and validation
activities must be documented in the Software Verification and Validation Plan
(SVVP). The SVVP is recommended to be divided into seven sections that contain
the verification plans for the SR, AD and DD phases and complete test
specifications for the unit, integration, system and acceptance testing. Following figure summarises when each software verification and validation sub-plan is
generated and documented in the preparation of master SVVP.
13. Each row of the figure corresponds to a
section of the SVVP and each column entry corresponds to a subsection. For
example, the entry 'ST Plan' in the SVVP/ST row means that the System Test Plan
is drawn up in the SR phase and placed in the SVVP section 'System Tests',
subsection 'Test Plan'.
14. Following figure shows the relationships between the sections and subsections of the SVVP.
Sections are shown in boxes. Relationships between sections are shown by lines
labeled with the verb in the relationship (e.g. 'contains'). The one-to-one
relationships are shown by a plain line and one-to-many relationships are shown
by the crow's feet.


No comments:
Post a Comment