Verifying documents at different phases:

Verifying requirements

 Requirements are difficult to develop because it is hard to

distinguish needs from wants.

 They usually change in later phases.

 They are the weakest link in the software chain.

The IEEE/ANSI definition of requirement is:

• A requirement is a condition of capability needed by a user

to solve a problem or achieve an objective.

• A requirement is a condition that must be met by or

possessed by a system or system component to satisfy a
contract, standard, specification or other formally imposed
documents.

Purpose of this phase of testing:

“Ensure that the user needs are properly understood before
we go any further”
Difficulty:

• To keep requirements strictly separate from solution to

those requirements.

• To realize that even in the best of worlds the requirements

are going to change.

Thus we need to handle and control the change through

proper verification of requirement and configuration
management of various versions for a solid framework for
later testing.
Requirements checklist:

A generic requirements verification checklist is:

• Precise, unambiguous and clear

• Consistent
• Relevant
• Testable: During program development and acceptance
testing, it will be possible to determine whether the item has
been satisfied.
• Traceable: Possible to trace each item through the various
stages of development.
When requirements are reviewed from testability
viewpoint:

All the vagueness is revealed.

e.g. It is hard to test what constitutes very good performance.

• Thus the question is: does it mean 24 hours or what?

Testability is closely linked to the concept of measurability.

• The more quantifiable the requirements the simpler it is to

derive test for the success of the system that results from
them.

Advantage of tester in requirements verification:

Learn something’s about the product and can now plan for
validation testing and how it is going to work
Verifying the functional design

Functional design is the process of translating user

requirements into the set of external interfaces. The output of
the process is the functional design specifications which
describe the product behavior as seen by an observer
external to the product.
Functional design checklist:

An extract from generic functional design verification

checklist:

• When a term is defined explicitly somewhere, try

substituting that definition in place of the term.
• When a structure is describes in words try to sketch a
picture of the structure being described.
• When a calculation is specified work at least two
examples by hand and give them as example in the
specification
• Watch for vague words like some, sometimes, often,
usually, ordinarily, customarily, most or mostly.
Goal of verifying a functional design:

To determine how successfully the user requirements have

been incorporated into the functional design.

Tractability:

• Every paragraph in the requirements should be reflected

in the functional design specification.

• One of the most common failing of the functional design

specifications is incompleteness.
Verifying the internal design

Internal design is the process of translating the functional

specification into a detailed set of data structures, data flows
and algorithm.

Output of the internal design:

• The internal design specification which shows how the

product is to be built.

• Multiple internal design specification, representing

successive levels of abstraction may be produced.

• Each of them should be verified.

Internal design checklist:

An extract from a typical internal design verification checklist:

• Does the design document contain a description of the

procedure that was used to preliminary design or is there is a
reference to such a procedure?
• Is there a model of the user interface to the computing
system?
• Is there a high level functional model of proposed
computing system?
• Are the major implementation alternative and their
evaluation represented in the documents?
What is done here is:

• Seeing how the product is going to be built and thinking

how the whole system is going to come together enable
testers to design additional internal-based tests.
• Using checklist, trace the path back to functional design
and back to requirements.
• Search for defects, but also think, “How would we test
that?”
• Description of internal documents gives the limit within the
product. It shows up boundary conditions; warn us about
performance and possible failure conditions and all kind of
other internal considerations.
Verifying the code

Coding is the process of translation the detailed design

specification into a specific set of code. The output of the
process is the source code itself.
Verifying the code involves the following activities:

1. Comparing the code with internal design specifications.

2. Examining the code against a language- specific checklist.
3. Using a static analysis tool to check for compliance with the
syntactic/content requirements.
4. Verifying the correspondence of terms in code with data
dictionary and with internal design specification.
5. Searching for new boundary conditions, possible
performance bottlenecks, and other internal considerations
which may form the basis for additional validation tests.
Code checklist – sample items:

The following are typical headings with a single example

under each from a generic code verification checklist:
• Data reference errors:
Is an unset or initialized variable referenced?
• Data declaration errors:
Are there variables with similar names?
• Computation errors:
Is the target variable of an assignment smaller than
the right-hand expression?
• Comparison errors:
Are the conversion rules for comparison between data
or variables of inconsistent type or length handled?
• Control flow errors:
Is there a possibility of premature loop exit?
• Interface errors:
If the module has multiple entry points, is a parameter
ever referenced that is not associated with the current
point of entry?
• Input/output errors:
Are there grammatical errors in program output text?
• Portability:
How is the data organized