Software

Verificatio
n

Verification Testing

Each verification activity

is a phase of the
testing life cycle.
What is Verification?

• If we review any document for

the purpose of finding faults, it is
called verification. .
• Verification is the process of
manually examining / reviewing a
document.
• Also known as static testing because
execution of program is not required. 2
 Verification
Testing
Basic verification methods

Verification is a “human” examination or review of the work

product.
Types of Review

Peer reviews Inspections Walkthroughs

• Inspections are generally considered the most formal.

Verification Testing
Peer Reviews
• Simplest way of reviewing
the documents / programs
• The document(s) /
program(s) is given to
some one else and ask to
review the document(s) /
program(s).
• May be very effective if
reviewers have:
o Domain knowledge
o Good programming skills
o Proper involvement

4
 Walkthroug
h
• Walkthroughs are more formal
and systematic than peer reviews.
• The following steps are followed
during walkthroughs:
– Author of the document presents the
document to a small group of two to
seven persons.
– Participants are not expected to
prepare anything.
– Only the presenter who is the author
prepares for the meeting.
– The document(s) is / are distributed
to all participants.
– The author introduces the material
in order to make them familiar with
it. 5

Walkthroug
• Disadvantages are: h
– Non-preparation of
participants.
– Document(s) presentation
by the author(s).
– Author may hide some
critical areas and
unnecessary emphasize
on some specific areas of
his / her interest.
– Author pride is involved
and that may make
him/her extra
about its success.
cautious 6
 Inspections
• Most structured and most formal
type of verification method.
• Presenter is not the author but
some other person who prepares
and understands the document
being presented.
• A team of three to six participants
are constituted which is led by an
impartial moderator.
• A presenter and a recorder are also
added to this team to assure that
the rules are followed and views
are documented properly. 7

Inspections
• A report is prepared by the moderator and
circulated to all participants.
• A final report is prepared after incorporating
necessary suggestions by the moderator.

8
 Inspections

Advantages
• Inspections improve SRS document and
faults are removed at an early stage without much
impact and cost.
• Verification may find faults that are nearly impossible to
detect during validation.

Inspectio
ns
S. Method Presenter Number of Prior Report Strengths Weaknesses
No. Participants preparation
1. Peer No one 1 or 2 Not required Optional Inexpensive Output
reviews but find is
some faults dependent
on
the
ability
of reviewer
2. Walkthrou Author 2 to Only Prepared Knowledge Find few
gh 7 presenter is by sharing faults and
participants required to presenter not
be prepared very
expensive
3. Inspections Someone 3 to All Prepared Effective Expensive
other than 6 participants by and and requires
author participants are required moderator find many very skilled
to faults participants
be
prepared
10
 Software Requirements
Specification Document
Verification
• Nature of the SRS Document
• The SRS should include the following:
• Expectations from the software
• Interfaces of the software
• Non-functional requirements
• Implementation difficulties and limitations

11

Software Requirements
1.
Specification
Introduction
1. Purpose
2. Scope
3. Definitions, Acronyms and Abbreviations
4. References
5. Overview

2. The Overall Description

1. Product Perspective
1. System Interfaces
2. Interfaces
3. Hardware Interfaces
4. Software Interfaces
5. Communications interfaces
6. Memory Constraints
7. Operations
8. Site Adaptation Requirements
2.2. Product Functions
3. User Characteristics
4. Constraints
5. Assumptions and Dependencies
6. Apportioning of Requirements

12
3. Specific Requirements
1.External interfaces
2.Functions
3.Performance Requirements
4.Logical Database Requirements
5.Design Constraints
3.5.1 Standards Compliance
6. Software System Attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
7. Organizing the Specific
Requirements
1. System Mode
2. User Class
3. Objects
4. Feature
5. Stimulus
6. Response
7. Functional Hierarchy
8. Additional Comments
13

Software Requirements
4. Specification
Change Management Process
5. Document Approvals
6. Supporting Information

14
 SRS Document Checklist
Characteristics and Organization of the SRS Document
• SRS document acts as a contract between the developer and
customer.
• This document should have the following characteristics:
• Correct,
• Unambiguous
• Complete
• Consistent
• Ranked For Importance And / Or Stability
• Modifiable
• Traceable
• Verifiable

15

SRS Document
Section - IChecklist

Name of reviewer
Organization
Group Number
Date of review
Project Title

16
 SRS Document
Section – Checklist
II
S. Description Yes/No/N Remark
No. A s

Introduction
1. Is the purpose of the project clearly defined?
2. Is the scope clearly defined?
3. Is document format as per standard / guidelines
(Eg. IEEE 830-1998)

4. Is the project formally approved by the customer?

5. Are all requirements, interfaces, constraints,
definitions etc listed in the appropriate sections?

17

SRS Document
Section – Checklist
II

Introduction
6. Is the expected response time from user’s
point of view, specified for
all
7. oDpoeralilonssta?ted requirements express the
expectations of the customer?
8. Are there areas not addressed in the SRS
document that need to be?
9. Are non-functional requirements stated?
10. Are validity checks properly defined for
every input condition?
18
 SRS Document
Section – Checklist
II

Ambiguity
11 Are functional requirements separated
from non-functional requirements?
12. Is any requirement conveying more than
one interpretation?
13. Are all requirements
clearly understandable?
14. Is any requirement conflict with or
duplicate with other requirements?
15. Are there ambiguous or
implied requirements?

19

SRS Document
Section – Checklist
II

Completeness
16. Are all functional and non-functional
requirements stated?
17. Are forms available with
validity checks?
18. Are all reports available in specified
format?
19. Are all references, constraints,
assumptions, terms and unit of
measures clearly stated?
20. Is analysis been performed to identify
missing requirements?
20
 SRS Document
Section – Checklist
II
Consistency
21. Are the requirements specified at a
consistent level of detail?
22. Should any requirement be specified in
more detail?
23. Should any requirement be specified in
less detail?
24. Are the requirements consistent with
other documents of the project?
25. Is there any difference in the stated
requirement at two places?

21

SRS Document
Section – Checklist
II

Verifiability
26. Are all stated requirements verifiable?
27. Are requirements written in a language
and vocabulary that the stakeholders can
understand?

28. Are there any non-verifiable words?

29. Are all paths of a use case verifiable?
30. Is each requirement testable?

22
 SRS Document
Section – Checklist
II
Modifiability
31. Are all stated requirements modifiable?
32. Have redundant requirements
been consolidated?
33. Has document been designed
to incorporate changes?
34. Is the format structure and style of the
document standard?
35. Is there any procedure to document a
change?

23

SRS Document
ChecklistTraceability
36. Can any requirement be traced back to
its origin or source?
37. Is every requirement
uniquely identifiable?
38. Are all requirements
clearly understandable for
implementation?
39. Has each requirement been cross
referenced to requirements in previous
project documents that relate?
40. Is each requirement identified such that
it facilitates referencing of each
requirement in future development and
enhancement efforts? 24
 SRS Document
Checklist
Feasibility
41. Is every stated requirement feasible?
42. Is any requirement non-feasible due to
technical reasons?

43. Is any requirement non-feasible due to

lack of resources?

44. Is any requirement feasible but very

difficult to implement?

45. Is any requirement very complex?

25

SRS Document
Checklist General
46. Is the document concise and easy to
follow?
47. Are requirements stated clearly and
consistently without contradicting
themselves or other requirements?

48. Are all forms, figures and

tables uniquely numbered?
49. Are hardware and other communication
requirements stated clearly?
50. Are all stated requirements necessary?

26
 Software Design Description Document
Verification
• SDD should address all design entities along with their
attributes
• SDD document may be organized as per IEEE STD 1016-
1998.
• SDD document verification checklist may
provide
opportunities to reviewers for focusing on important areas of
the design.

27

Software Design Description

Document
1. Introduction Verification
1. Purpose
2. Scope
3. Definitions and acronyms
2. References
3. Decomposition description
1. Module decomposition
1. Module 1 description
2. Module 2 description
2. Concurrent process decomposition
1. Process 1 description
2. Process 2 description
3. Data decomposition
1. Data entity 1 description
2. Data entity 2 description

28
 SDD Document
4.
Verification
Dependency description
1. Intermodule dependencies
2. Interprocess dependencies
3. Data dependencies
5. Interface description
1. Module Interface
1. Module 1 description
2. Module 2 description
2. Process interface
1. Process 1 description
5.2.2. Process 2 description

6. Detailed design
1. Module detailed
design 1.Module 1
detail
2.Module 2 detail
2.Data detailed design
1.Data entry 1 detail
2.Data entry 2
detail 29

SDD
S.N Description
Checklist Yes/No/N Remarks
o. A

General Issues
1. Is the document easy to read?
2. Is the document easy to understand?
3. Is the document format as per IEEE std. 1016-1998?
4. Does the document look professional?
5. Is system architecture (including hardware, software,
database and data communication structures)
specified?

30
 SDD
Checklist
System Architecture
6. Is the architecture understandable?
7. Are figures used to show the architecture of the
system?

8. Are all essentials described clearly and

consistently? (Essentials may be software
component(s), networks, hardware, databases,
operating system etc).

10. Is the software design consistent with existing

policies, guidelines and standards?

31

SDD
Checklist
Software Design

11. Is design as per standards?

12. Are all design entities described?

13. Are all attributes defined clearly?

14. Are all interfaces shown amongst the design

entities?

15. Are all stated objectives addressed?

16. Is the data dictionary specified in tabular form?

32
 SDD
Checklist
Data Design
17. Are all definitions of data elements included in
the data dictionary?

18. Are all appropriate attributes that describe each

data element included in the data dictionary?

19. Is interface data design described?

20. Is data design consistent with existing policies,
procedures, guidelines, standards and
technological directives?

33

SDD
Checklist
Interface Design
21. Is the user interface for every application
described?

22. Are all fields available on every screen?

23. Is the quality of screen acceptable?
24. Are all major functions supporting each interface
addressed?

25. Are all validity checks for every field specified?

34
 SDD
Checklist
Traceability
26. Is every requirement stated in the SRS addressed
in design?

27. Does every design entity addresses at least one

requirement?
28. Is there any missing requirement?
29. Is Requirement Traceability Matrix (RTM)
prepared?
30. Does the RTM indicates that every requirement
has been addressed clearly?

35

Source Code
Reviews
• A source code review involves
one or more reviewers examining
source code and providing
feedback to the developers, both
positive and negative.
• Reviewers should not be from
the development team.
• Source code may be reviewed
for:
• Syntax
• Standards defined
• Readability
• Maintainability to reviewers
36
for focusing on important areas
of the design.
 Source Code Reviews
Issues Related to Source Code Reviews
• Always use meaningful variables.
• Avoid confusing words in names.
• Declare local variables and avoid global variables to the
extent possible.
• Minimize the visibility of variables.
• Do not overload variables with multiple meanings.
• Define all variables with meaningful, consistent and clear
names.
• Do not unnecessary declare variables.
• Use comments to increase the readability of the source
code.
• Generally, comments should describe what the source
code does and not how.
37

Source Code Reviews

Issues Related to Source Code Reviews
• Always update comments when change the source
code.
• Use spaces and not TABS.
• All divisors should be tested for zero or garbage value.
• Always remove unused lines of the source code.
• Minimize the module coupling and maximize the
module strength.
• File names should only contain A-Z, a-z, 0-9, ‘_’ and
‘.’.
• The source code file names should be all lower case.
• All loops, branches and logic constructs should be
complete, correct and properly nested and also avoid
deep nesting.
38
 Source Code Reviews
Issues Related to Source Code Reviews
• Complex algorithms should be thoroughly commented.
• The reasons for declaring static variables should be
given.
• Always ensure that loop iterate the correct number of
times.
• When memory is not required, it is essential to make it
free.
• Stack space should be available for running a recursive
function. Generally, it is better to write iterative
functions.
• Use existing source code as much as possible. However,
do not over rely on this source code during testing. This
portion should also be tested thoroughly.
39

Source Code
S.No Description
Checklist Yes/No/N Remarks
. A

Structure
1. Does the source code correctly and completely
implement the design?

2. Is there any coding standard being followed?

3. Has the developer tested the source code?
4. Does the source code execute as expected?
5. Is the source code clear and easy to understand?

40
 Source Code
6.
Checklist
Are all functions in the design coded?
7. Is the source code
properly structured?
8. Are there any blocks of repeated
source code that can be combined to
form a single module?
9. Does any module very complex and
should be decomposed in two or more
modules?
10. Does the source code fault tolerant?

41

Source Code
Checklist
Variables
11. Are all variables clearly defined with appropriate
names?
12. Are there any redundant and unused variables?
13. Is there unnecessary usage of global variables?
14. Are variable declarations properly commented?
15. Are all variables properly initialized?
16. Is scope of every variable minimized?
17. Is any variable name ambiguous?
18. Are all variable names spelled correctly and
consistently?

42
 Source Code
Checklist
Comments

19. Is readability of the source code acceptable?

20. Is the source code well commented and
documented properly?
21. Are all given comments necessary?
22. Is there any requirement of additional
comments?
23. Are all comments consistent with the source
code?

43

Source Code
Checklist
Loop and Branches

.24 Are all loops, logic constructs and

. branches correct, complete and
appropriately nested?

25. Does the source code make use of infinite

loop?

26. Does the loop execute the specified

number of times?

27. Are loop exit conditions accurate?

28. Does every case statement has a default?

44
 Source Code
Checklist
General
29. Is every allocated memory de-allocated?
30. Does the source code make use of exception
handling?
31. Does the source code appear to pose a security
concern?
32. Does the source code avoid deadlocks?
33. Does the implementation match
the documentation?
34. Is there any identifier that conflict with keyword?
35. Is the source code maintainable?

45

User Documentation Verification

• User documentation should be reviewed thoroughly and
proper consistency should be maintained in all documents.
• A checklist helps the review process.
• User documentation checklist may include:
– Installation Issues
– Operational Issues
– Issues of tables, graphs and figures

46
 User Documentation
Verification
S.N Description Yes/No/ Remarks
o. NA
General Issues
1. Does the document easy to read?
2. Does the document easy to understand?
3. Is the document well organized? Are things
easy to find?
4. Does the document look professional?
5. Are spelling and grammar correct?
6. Are all references properly placed in text?
7. Is consistency maintained?
8. Are all abbreviations and assumptions properly
written at proper places?

47

User Documentation
Verification
Installation Issues
9. Is everything operated as stated in the
document?

10. Is there any step omitted?

11. Does it specify minimum
system configuration requirement?

12. Does it specify reasons of failure of a

particular activity?

48
 User Documentation
Verification
Operational Issues

13. Does it clearly describe all toolbars, menus,

commands and options?
14. Does toolbars, menus, commands options
operate as stated?
15. Are examples documented correctly?
16. Are all steps explained?
17. Does document specifies all steps as accepted
to operate a graphical user interface (GUI)?
18. Does it include sample screenshots identical to
GUI?

49

User Documentation
Verification
Issues of tables, graphs and figures
19. Are all tables, graphs and figures properly
numbered?
20. Are they identical to actual GUI?
21. Are they properly referenced in the text?
22. Are they properly placed?
23. Are they consistent with previous tables, graphs
and figures?
24. Are all given tables, graphs and figures
necessary?
25. Are there any requirement of new figures,
graphs or tables?

50
 Software Project
Audits
• Auditors are different from the
developers and testers and may not have
any involvement in the project.
• Auditors examine the progress of the
project and quality of the processes with
respect to many attributes like
– Project Planning
– Management
– Quality Management
– Resourcing
– Users
– Development Approaches
– Testing
– Application Architecture
– Data Architecture
51
– Technical Architecture Issues
– Issues of tables, graphs and figures

Software Project Audits

• Relevance Scale
– Used to measure the
relevance of any
attribute at the time of
auditing the project.
– Varies from 1-5 scale.

52
 Software Project Audits
• Theory and Practice Scale
– Theory and practice scale is very useful and
indicate the implementation status of any
attribute.
– Project audits must be carried out many times
during development.

53

Software Project Audits

• Project Audit
and Review
Checklist
– This checklist has been
designed by Metty Baiz
and Nancy Costa at
Princeton University,
New Jersey, USA.
– All activities are
reviewed on the basis of
its relevance and
strength/weakness at any
point of time.
54