Software verification

• Verification is the process of manually examining

/ reviewing a document.
• The document may be SRS, SDD, the program
itself or any document prepared during any phase
of software development.
• We may call this as static testing because the
execution of the program is not required. We
evaluate, review and inspect documents which
are generated after the completion of every phase
of software development.
• As per IEEE, “verification is the process of
evaluating the system or component to
determine whether the products of a given
development phase satisfy the conditions
imposed at the start of that phase”
 VERIFICATION METHODS
• The objective of any verification method is to
review the documents with the purpose of
finding faults.
• Many methods are commonly used in practice
like peer reviews, walkthroughs, inspections,
etc.
• Verification helps in prevention of potential
faults, which may lead to failure of software.
• After the completion of the implementation
phase, we start testing the program by
executing it.
• We may carry out verification also by
reviewing the program manually and
examining the critical areas carefully.
• However, only verification is possible in the
phases prior to implementation like the
requirement phase, the design phase and
even most of the implementation phase.
 Peer Reviews
• This is the simplest way of reviewing the
documents / programs to find out faults during
verification.
• We give the document(s) / program(s) to
someone else and ask to review the document(s)
/ program(s).
• We expect views about the quality of the
document(s) and also expect to find faults.
• informal activity
Peer Reviews
• Our thrust should be to find faults in the
document(s) / program(s) and not in the persons who
have developed them.
• The activities involved may be SRS document
verification, SDD verification and program verification.
• The reviewer may prepare a report of observations and
findings or may inform verbally during discussions.
• This is an informal activity to be carried out by peers
and may be very effective if reviewers have domain
knowledge, good programming skills and proper
involvement.
 Walkthroughs
• Walkthroughs are more formal and systematic than peer reviews
• In a walkthrough, the 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.
• During the meeting, the author introduces the material in order to
make them familiar with it. All participants are free to ask questions.
All participants may write their observations on any display
mechanism like boards, sheets, projection systems, etc. so that every
one may see and give views. After the review, the author writes a
report about findings and any faults pointed out in the meeting.
Walkthroughs
• The disadvantages of this system are the non-
preparation of participants and
incompleteness of the document(s) presented
by the author(s).
• Walkthroughs may help us to find potential
faults and may also be used for sharing the
documents with others.
 Inspection
• Many names are used for this verification
method like formal reviews, technical reviews,
inspections, formal technical reviews, etc.
• This is the most structured and most formal
type of verification method and is commonly
known as inspections
• These are different from peer reviews and
walkthroughs.
• The presenter is not the author but some
other person who prepares and understands
the document being presented.
• This forces that person to learn and review
that document prior to the meeting.
• The document(s) is / are distributed to all
participants in advance in order to give them
sufficient time for preparation.
• Rules for such meetings are fixed and
communicated to all participants
• 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.
• Every person in the group participates openly, actively and follows
the rules about how such a review is to be conducted.
• Everyone may get time to express their views, potential faults and
critical areas.
• Important points are displayed by some display mechanism so that
everyone can see them.
• The moderator, preferably a senior person, conducts such
meetings and respects everyone’s views.
• The idea is not to criticize anyone but to understand their views in
order to improve the quality of the document being presented.
• Sometimes a checklist is also used to review the document.
• After the meeting, a report is prepared by the
moderator and circulated to all participants.
• They may give their views again, if any, or discuss with
the moderator.
• A final report is prepared after incorporating necessary
suggestions by the moderator.
• Inspections are very effective to find potential faults
and problems in the document like SRS, SDD, source
code, etc.
• Critical inspections always help find many faults and
improve these documents, and prevent the propagation
of a fault from one phase to another phase of the
software development life cycle.
Applications
 SOFTWARE REQUIREMENTS SPECIFICATION
(SRS) DOCUMENT VERIFICATION
• The outcome of the first phase of the software
development life cycle is the SRS document.
• What do we expect from the system?’
• After the finalization of the SRS, the developer
knows what to develop and the customer knows
what to expect.
• The SRS also becomes a legal document to
resolve any conflict between the customer and
the developer.
 1.Nature of SRS document
1. Expectations from the software:
2. Interfaces of the software: The software will interact with many
persons, hardware, other devices and external software.

3. Non-functional requirements:
4. Implementation difficulties and limitations
The SRS writer(s) should not include design and implementation details. It
should be written in simple, clear and unambiguous language which may
be understandable to all developers and customers.
 Characteristics and organization of SRS
document
• The SRS document acts as a contract between
the developer and customer.
• This document should have the following
characteristics as given in IEEE recommended
practice for software requirements
specifications (IEEE std. 830 – 1998) [IEEE98a]:
“Correct, unambiguous, complete, consistent
and ranked for importance and / or stability,
verifiable, modifiable, traceable.”
The general organization
of the SRS document
 SRS document checklist
• The SRS document is reviewed by the testing person(s) by
using any verification method (like peer reviews,
walkthroughs, inspections, etc.).
• A checklist is a popular verification tool which consists of a
list of critical information content that a deliverable should
contain.
• A checklist may also look for duplicate information,
missing information, unclear information, wrong
information, etc. Checklists are used during reviewing and
may make reviews more structured and effective.
• An SRS document checklist should address the following
issues:
 An SRS document checklist should address the following issues:

• Correctness
• Ambiguity
• Completeness
• Consistency
• Verifiability
• Modifiability
• Traceability
• Feasibility
A generic checklist
 SOFTWARE DESIGN DESCRIPTION (SDD)
DOCUMENT VERIFICATION
• We prepare the SDD document from the SRS
document. Every requirement stated therein is
translated into design information required for
planning and implementation of a software
system
• Our objective is to partition the system into
separate units that can be considered,
implemented and changed independently.
• Two popular design techniques are function
oriented design and object oriented design.
• Our purpose is to prepare a quality document
that translates all requirements into design
entities along with its attributes.
• The verification process may be carried out many
times in order to improve the quality of the SDD.
• The SDD provides a bridge between software
requirements and implementation.
• Hence, strength of the bridge is the strength of
the final software system.
 SDD document checklist
• The SDD document verification checklist may
provide opportunities to reviewers for
focusing on important areas of the design.
• The software design starts as a process for
translating requirements stated in the SRS
document in a user-oriented functional
design.
 SOURCE CODE REVIEWS
• A source code review involves one or more reviewers
examining the source code and providing feedback to the
developers, both positive and negative.
• Reviewers should not be from the development team.
• Review the source code for syntax, standards defined,
readability and maintainability.
• Reviews will have a standard checklist as a guide for finding
common mistakes and to validate the source code against
established coding standards.
• The source code reviews always improve the quality and
find all types of faults.
 Issues related to source code reviews
1. Always use meaningful variables.
2. Avoid confusing words in names. Do not abbreviate ‘Number’ to ‘No’; ‘Num’ is a
better choice.
3. Declare local variables and avoid global variables to the extent possible. Thus,
minimize the scope of variables.
4. Minimize the visibility of variables.
5. Do not overload variables with multiple meanings.
6. Define all variables with meaningful, consistent and clear names.
7. Do not unnecessarily declare variables.
8. Use comments to increase the readability of the source code.
9. Generally, comments should describe what the source code does and not how the
source code works.
10. Always update comments while changing the source code.
11. Use spaces and not TABS.
12. All divisors should be tested for zero or garbage value.
13. Always remove unused lines of the source code.
14. Minimize the module coupling and maximize the module strength.
15. File names should only contain A-Z, a-z, 0-9, ‘_’ and ‘.’.
16. The source code file names should be all lower case.
17. All loops, branches and logic constructs should be complete, correct
and properly nested and also avoid deep nesting.
18. Complex algorithms should be thoroughly explained.
19. The reasons for declaring static variables should be given.
20. Always ensure that loops iterate the correct number of times.
21. When memory is not required, it is essential to make it free.
22. Release all allocated memory and resources after the usage.
23. Stack space should be available for running a recursive function.
Generally, it is better to write iterative functions.
24. Do not reinvent the wheel. 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.
Checklist for source code reviews
 USER DOCUMENTATION VERIFICATION
• installation guide, beginner’s guide / tutorial, system
administration guide, etc. and these are known as user
manuals
• Some are prepared for internal purposes like SRS, SDD,
program listing, cross-reference listing, test suite, etc., and
are known as documentation manuals.
• The documents which are given to the customer are also
important for the overall success of the project.
• User documentation may be provided as a user manual in
electronic form, as a printed booklet, or in the form of
online help.
User Documentation Checklist
 SOFTWARE PROJECT AUDIT
• Audit of a software project is a very important
activity and may be carried out at any time
during the software development life cycle.
• Generally, auditors are appointed by the top
management to review the progress of the
project.
• The auditors are different from the developers
and testers and may not have any involvement
in the project.
• They may 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 and technical architecture.
• The audit process is a verification activity and
the auditor prepares an audited report after
examining the relevant records and
documents.
• This report may help the management to initiate
timely action, if required.
• The management may get to know about delays, if
any, in the development, involvement of users,
implementation of software engineering practices and
standards, status of risk assessment activities, etc.
• A project audit and review checklist has been
developed by Hetty Baiz and Nancy Costa at Princeton
University [HETT01] which is an excellent work for
auditing any software project.
 1. Relevance Scale
• A relevance scale has been given in project
audit and review checklist to measure the
relevance of any attribute at the time of
auditing the project
Theory and practice scale
Project audit and review checklist
 Case Study
• University Registration System:
 II. Creating Test Cases from requirements
and Use Cases
• We prepare ‘Software requirements and
specifications’ document to define and specify
user requirements.
• In the initial years of software development,
requirement writers used to write stories to
explain the expected behaviour of the system
and its interactions with the external world.
• Ivar Jacobson and his team [JACO99] gave a new dimension
and direction to this area and developed a Unified Modeling
Language (UML) for software development.
• They introduced use case approach for requirements
elicitation and modeling.
• This is a more formal way to write requirements.
• The customer knows what to expect, the developer
understands what to code, the technical writer comprehends
what to document and the tester gets what to test.
• The use cases address primarily the functional
requirements, meaning thereby, the perspective of the users
sitting outside the system.
• Use cases capture the expectations in terms of achieving
goals and interactions of the users with the system.
 USE CASE DIAGRAM AND USE CASES
• Use case diagram is also used along with use
cases to explain the functionality of the system.
• This is a graphical representation and gives the
top view of the system along with its users and
use cases.
• Use cases and use case diagrams are normally
used together to define the behaviour of a
system.
• A use case diagram visually explains what
happens when an actor interacts with the
system.
• Actor represents the role of a user that
interacts with the system. They are outsiders
to the system and can be human beings, other
systems, devices, etc.
• A use case is started by a user for a specific
purpose and completes when that purpose is
satisfied. It describes a sequence of actions a
system performs to produce an observable
output for the interacting user (actor).
• A use case describes who (any user) does what
(interaction) with the system, for what goal,
without considering the internal details of the
system. A complete set of use cases explains the
various ways to use the system. Hence, use cases
define expected behaviours of the system and
helps us to define the scope of the system.
 Identification of Actors
• An actor represents the role of a user that interacts
with the system. An actor may be a human being
or a system that may interact with a use case
keeping in view a particular goal in mind
• University registration system
(i) Administrator
(ii) Student
(iii) Faculty
(iv) Data entry operator
(i) Administrator: Able to add, modify or delete a programme,
school, scheme, paper, student, faculty and login
information. Able to generate student registration card and
other reports.
(ii) Student: Able to add and modify his/her details and register
for papers to be studied in
the current semester. Able to generate student registration
card.
(iii) Faculty: Able to generate desired reports.
(iv) Data entry operator: Able to add, modify or delete student
and faculty information.
 Identification of Use Cases
• After the finalization of requirements, we expect to create use
cases for the system. Some guidelines for the creation of use
cases are given as:
(i) Every use case should have a specified functionality.
(ii) Every use case will have a name. Every name should be unique,
meaningful and purposeful to avoid confusion in the system.
(iii) One or more actors will interact with a use case.
(iv) An actor will initiate a use case.
(v) The role of actors should always be clearly defined for every
use case. Who will initiate the use case and under which
conditions, should be clearly specified.
 Drawing of Use Case Diagram
• The use case diagram shows actors, use cases
and the relationship between them.
• In use case diagram, actors are represented as
stick figures and
• Use cases are represented as ovals.
• The relationship between an actor and a use
case is represented by a solid arrow.
If the system is small, one diagram may be sufficient to
represent the whole system, but for
large systems, we may require to represent the whole
system in many diagrams.
 Writing of Use Case Description
• Actors interact with the use cases for
predefined purposes. Hence, each actor does
something with the system and the system
responds accordingly.
• Each step is considered as a sequence of
events and is called a flow. There are two
types of flows:
(i) Basic Flow: It is the main flow and describes
the sequence of events that takes place most
of the time between the actor and the system
to achieve the purpose of the use case.
(ii) Alternative Flows: If the basic flow is not
successful due to any condition, the system
takes an alternative flow. An alternative flow
may occur due to failure of an expected service
because of occurrence of exceptions/errors.
 GENERATION OF TEST CASES FROM USE
CASES
• We may start writing the test cases as soon as use cases
are available.
• A systematic approach may include the following steps:
(i) Generation of scenario diagrams
(ii) Creation of use case scenario matrix
(iii) Identification of variables in a use case
(iv) Identification of different input states of available
variables
(v) Design of test case matrix
(vi) Assigning actual values to variables
 Generation of Scenario Diagrams
• A use case scenario is an instance of a use
case or a complete path through the use case
• The basic flow is one scenario and every
alternative path gives another scenario
• Use case scenarios may also be generated due
to various combinations of alternative flows.
• The basic flow is represented by a straight
arrow and the alternative flows by the curves
• Some alternative flows return to the basic
flow, while others end the use case.
• At the end of the basic flow, a post-condition
is generated while at the starting of the basic
flow, a pre-condition is required to be set.
• The basic and alternative flows for login use
case are given in Figure
• there is one basic flow which will be executed
when the correct login Id and password are
given. This basic flow is expected to be
executed most of the time.
• If any input (Login Id or password) is invalid,
then the alternative flow will be executed and
the actor will return to the beginning of the
basic flow. If at any time, the user decides to
exit, then alternative flow 3 will be executed.
 Creation of Use Case Scenario Matrix

• Use case scenario diagrams generate many

scenarios due to the basic flow, every
alternative flow along with the basic flow and
various combinations of the basic and
alternative flows.
• A scenario matrix gives all possible scenarios
of the use case scenario diagram. The scenario
matrix given in Table
Identification of Variables in a Use Case
• We have to identify all input variables which have
been used in every use case.
• A variable may also be used as a selection variable
where many options are available for a variable.
• A selection variable may be values of buttons
available which provide input to the use case at
some intermediate step of the use case.
• ‘Updation confirmed?’ will provide two options to
an actor ‘Yes/No’
• The following variables are used in the login use case:
(i) Login Id
(ii) Password
(iii) Old password
(iv) New password
(v) Confirm password

• These variables are inputs to the system and when an

input or combination of specified inputs is given, a
particular behaviour (output) is expected from the
system.
• Hence, identification of these variables is important and
helps in designing the test cases.
 Identification of Different Input States of a
Variable
• An input variable may have different states and the behaviour of
the system may change if the state of a variable is changed.
• Any variable may have at least two states i.e. valid state and
invalid state.
• If we consider the ‘Login Id’ variable of the login use case, it is
expected that the
• “Login Id should be alphanumeric of length 11 characters and only
digits from 0 to 9 are allowed.
• Alphabets, special characters and blank spaces are not allowed.”
Hence, one state is the valid login Id as per the given directions
and another state is the invalid login Id which is different from the
given directions.
 Design of Test Case Matrix
• One way to do so is to create a test case matrix
where rows of the matrix contain test cases
• and the first column contains the scenario
name and description and the remaining
columns may contain the various input variables
including the selection variables.
• The last column contains the expected output
when these inputs are given to the system. A
typical test case matrix is given in Table
 Assigning Actual Values to Variables
• In test case matrix, we have written only ‘valid input’,
‘invalid input’ and ‘not applicable (n/a)’ in the input value
columns of various variables.
• Now, we want to assign actual values in these columns in
order to use them at the time of execution to get the actual
output.
• We may also add two additional columns with titles ‘Actual
output’ and ‘Pass/fail’ which will be used at the time
• of executing these test cases. There should be at least one
test case for each scenario, but more test cases may be
designed, depending upon availability, time and resources.
 iii. GUIDELINES FOR GENERATING VALIDITY
CHECKS
• We may have to give many inputs to a
program via forms, data files and / or input
statement(s). Ideally,
• we want to enter correct data and for this
purpose we should test various conditions
with invalid inputs to the program. Some of
the guidelines are
 1. Data Type
• If input x is defined as an integer, then x should also be
checked for float, char, double, etc. values.
• In the login form, we should clearly state the type of both
the inputs i.e. Login Id and password.
• For example, the Login Id input should be numeric and
should not accept alphabets, special characters and blank
spaces.
• Similarly, the password input will accept alphabets, digits,
hyphen and underscore but will not accept blank spaces.
• We should generate validity checks for every ‘do’ and every
‘do not’ case.
 Data Range

• We should generate validity checks for both

valid and invalid range of inputs.
 Special Data Conditions
• Some special conditions may need to be
checked for specified inputs. For example, in
the e-mail address, ‘@’ and ‘.’symbols are
essential and must be checked.
• We should write validity checks for such
special symbols which are essential for any
specific input
 4. Mandatory Data Inputs
• Some inputs are compulsory for the execution
of a program. These mandatory fields should
be identified and validity checks be written
accordingly.
• We should provide validity checks to verify
that mandatory fields are entered by the user.
 5.Domain Specific Checks
• Some validity checks should be written on the
basis of the expected functionality.
• In the URS, no two semesters should have a
common paper. The roll number should be used
as a login Id.
• A student cannot select more than the required
number of elective papers in a semester.
• These domain specific issues should be written as
validity checks in order to verify their correctness.
 STRATEGIES FOR DATA VALIDITY
• Valid data means correct data which is expected in
every software. The software should provide checks for
validating data entered into the system.
• Whenever and wherever we attempt to enter invalid
data, an appropriate message should be displayed.
• Data validity strategies are often influenced by the
design of the software.
• Three popular strategies for data validation are
discussed which may be applied at the early phases of
the software development life cycle.
 1. Accept Only Known Valid Data
• We all want to enter valid data into the system.
• If our software accepts only correct data, our design is
a successful design.
• If it does not happen, we may enter invalid data into
the system, which may further complicate many issues.
• Invalid data may force the software to behave
unexpectedly and may lead to a failure.
• Hence, software should accept only input(s) that is /
are known to be safe and expected.
 Reject Known Bad Data
• If the input data is not as expected, the software
should reject it and an appropriate error message
should be displayed.
• We should check the data type from the form itself.
If the integer type x is the input and we enter x as a
float, an error should immediately be displayed.
• The software should accept values in the specified
range. If the input is beyond range, it should not be
accepted at all.
 Sanitize All Data
• Data sanitization is the process of purifying (filtering) undesirable
data in order to make it harmless and safe for the system.
• We may sanitize data at the input stage where data is entered by
the user.
• We may also sanitize the data at the output stage where data is
displayed to the user in such a way that it becomes more useful
and meaningful.
• For example, when an integer variable is used, its lower and
upper permissible limits must be specified and provisions should
be made in the program to prevent the entry of any value outside
the permissible limit.
Example-write VC and TC
 DATABASE TESTING
• In many software applications, we create and
maintain databases. Items are added, viewed,
edited and deleted regularly as per
requirements of the users.
• These operations are generally performed
using the interface forms where special
provisions are provided for such operations.
• As a tester, we may like to verify the following:
(i) Is an item added in the database after the
execution of ‘Add’ operation?
(ii) Is an operation deleted from the database
after the execution of ‘Delete’ operation?
(iii) Is an item edited as desired in the database
after the execution of ‘Edit’ operation?
(iv) Is an item viewed as expected after correctly
retrieving from the database after the
execution of ‘View’ operation?