Unit No.

Static Testing
 3. Static Testing
3.1. Static Techniques – Review
3.1.1. Review Process (Informal & Formal)
3.1.2. Desk Checking,
3.1.3. Technical or Peer Review
3.1.4. Walkthrough
3.1.5. Inspection
3.2. Static Techniques – Static Analysis
3.2.1. Data flow analysis
3.2.2. Control flow analysis,
3.2.3. Static Analysis by Tools (Automated Static Analysis)
Case Study on Preparation of Inspection Checklist
 Static testing
• Static testing is a verification process used to test the application without
implementing the code of the application. And it is a cost-effective process.
• To avoid the errors, we will execute Static testing in the initial stage of
development because it is easier to identify the sources of errors, and it can
fix easily.
• In other words, we can say that Static testing can be done manually or with
the help of tools to improve the quality of the application by finding the error
at the early stage of development; that is also called the verification process.
• We can do some of the following important activities while performing static
testing:
• Business requirement review ,Design review ,Code walkthroughs,The test
documentation review
When we performed Static Testing?

• To perform static testing, we need to follow the below steps:

• Step1: To review the design of the application entirely, we
will perform the inspection process.
• Step2: After that, we will use a checklist for each document
under review to make sure that all reviews are covered
completely.
 Implement several activities while performing static testing, which are discussed in the following table:
Activities Explanation
Architecture •The architecture review activities contain all business-level processes such as network
Review diagram, load balancing, server locations, protocol definitions, test equipment,
database accessibility, etc.
Use Cases •It is used to authenticates all the end-user actions along with associated input & output.
Requirements •If the use case is more comprehensive and detailed, we can make more precise and
Validation inclusive test cases.

Functional •The functional requirement validation activity is used to make sure that all necessary
Requirements elements identify correctly.
Validation •And it also took care of the software, interface listings, network requirements,
hardware, and database functionality.
Field Dictionary •In the field dictionary validation, we will test each field in the user interface specified
Validation to create field-level validation test cases.
•And we can check the fields for error messages, minimum or maximum length, list
values, etc.
Prototype/Screen •The prototype validation activity contains the authentication of requirements and uses
Mockup Validation cases.
Static Testing Techniques
 Review
• In static testing, the review is a technique or a process implemented to find the
possible bugs in the application. We can easily identify and eliminate faults and
defects in the various supporting documents such as SRS [Software
Requirements Specifications] in the review process.
• In other words, we can say that a review in Static Testing is that where all the
team members will understand about the project's progress.
• In static testing, reviews can be divided into four different parts, which are as
follows:
1. Informal reviews
2. Walkthroughs
3. Technical/peer review
4. Inspections
• Informal reviews

In informal review, the document designer place the contents in front of

viewers, and everyone gives their view; therefore, bugs are acknowledged in
the early stage.
• In this type of review, the author of the document presents it in front of the
team. The team in this review consists of senior management, business
clients, development team, etc. The main aim of informal reviews is to get
casual feedback from the team members in the early stages of the product.
• Informal reviews are applied many times during the early stages of the life
cycle of the document. A two person team can conduct an informal review. In
later stages these reviews often involve more people and a meeting. The goal
is to keep the author and to improve the quality of the document. The most
important thing to keep in mind about the informal reviews is that they
are not documented.
• Walkthrough

The walkthrough review is used to performed by a skilled person or expert to

verify the bugs.
• Therefore, there might not be problem in the development or testing phase.
• Document walkthrough is generally performed by experts or senior members
of the team.
• These walkthroughs are a check for the quality of the product and also to see
if the team is working in the right direction.
•
• Walkthrough:
• It is not a formal process
• It is led by the authors
• Author guide the participants through the document according to his or her thought
process to achieve a common understanding and to gather feedback.
• Useful for the people if they are not from the software discipline, who are not used
to or cannot easily understand software development process.
• Is especially useful for higher level documents like requirement specification, etc.

• The goals of a walkthrough:

• To present the documents both within and outside the software discipline in order
to gather the information regarding the topic under documentation.
• To explain or do the knowledge transfer and evaluate the contents of the document
• To achieve a common understanding and to gather feedback.
• To examine and discuss the validity of the proposed solutions
• Technical review:
• It is less formal review
• It is led by the trained moderator but can also be led by a technical expert
• It is often performed as a peer review without management participation
• Defects are found by the experts (such as architects, designers, key users)
who focus on the content of the document.
• In practice, technical reviews vary from quite informal to very formal
• The goals of the technical review are:
• To ensure that an early stage the technical concepts are used correctly
• To access the value of technical concepts and alternatives in the product
• To have consistency in the use and representation of technical concepts
• To inform participants about the technical content of the document
• Peer review
•
In Peer review, we can check one another's documents to
find and resolve the bugs, which is generally done in a team.
• It’s an informal review with teammates to check the common
mistakes like spelling mistakes, requirement workflow, etc to
gather their understanding of the document and get reviews in
order to enhance the quality of the documents.
• Inspection
•
In review, the inspection is essentially verifying the document by the higher authority, for
example, the verification of SRS [software requirement specifications] document.
• Inspection:
• It is the most formal review type
• It is led by the trained moderators
• During inspection the documents are prepared and checked thoroughly by the reviewers
before the meeting
• It involves peers to examine the product
• A separate preparation is carried out during which the product is examined and the defects
are found
• The defects found are documented in a logging list or issue log
• A formal follow-up is carried out by the moderator applying exit criteria
• The goals of inspection are:
• It helps the author to improve the quality of the document under
inspection
• It removes defects efficiently and as early as possible
• It improve product quality
• It create common understanding by exchanging information
• It learn from defects found and prevent the occurrence of similar
defects
 The stages in the process of Inspection are as below:
• Planning: In this stage, a plan to conduct the review is prepared. This plan includes the
documents which need to be part of the review, people who will be involved in the review,
and actions that need to be taken based on the feedback.
• Overview Meeting: In this meeting, the plan created as part of the planning phase is shared
with the team and the overview is given about the inspection so that everyone who is part of
the inspection is well prepared.
• Preparation: In this phase, all the team members who are part of the inspections prepare
themselves for the software or the documents which are under inspection and gather the
information they want to discuss.
• Inspection Meeting: This is the actual meeting where the document or the software is
discussed with the team members feedback is gathered to improve the software quality.
• Rework: As part of this phase, team members work on the feedback given as part of the
meeting and enhance the software for good quality.
• Follow-up: This the follow-up phase where rework is discussed and feedback is gathered on
the rework to improve the quality further.
 The inspection process consists of five types of participants
who have defined roles. They are as follows:
• Moderator: He coordinates each phase with all the team members. Moderator
schedules the meetings and follows up after the rework.
• Author: An author is responsible for writing the documents under inspections
and take care of the feedback fixes to improve the document quality.
• Scribe: A scribe is usually the logger of the meeting. The scribe keeps track of
all the feedback provided during the meeting and also the questions which
need more information.
• Reviewer: A reviewer checks the document for defects and quality purposes.
• Manager: A manager decides the inspection process and takes care that the
process meets the guidelines and is as expected.
 Desk Checking
•Desk checking is an informal manual test that programmers can use to
verify coding and algorithm logic before a program launch.
•This enables programmer to spot errors that might prevent a program
from working as it should.
•Modern debugging tools make desk checking less essential than it was
in the past, but it can still be a useful way of spotting logic errors.
Advantages
•Help catch and fix them before a program goes through a formal run.
•Running a desk check is quick and inexpensive.
•Errors spotted and fix in early stage of development
•Errors may also be harder to identify at a later stage
• Problem Description: Calculate the discounted price of an item purchased.
(Note: a problem description is not normally specified in a desk check, it is
only included to assist in understanding the problem.)
• The following example shows desk checking involving sequence, executing
instructions one after the other.
• Sequence involves executing all instructions once, from top to bottom, one
after the other.
• Algorithm (with line numbers added for the Desk Check)
• 1 calcDiscountPrice()
• 2 Input price, discountPercent
• 3 discount = price * discountPercent / 100
• 4 discountPrice = price – discount
• 5 Display discountPrice
• 6 STOP
3.2. Static Techniques – Static Analysis
3.2.1. Data flow analysis
3.2.2. Control flow analysis,
3.2.3. Static Analysis by Tools (Automated Static Analysis)
 Static Analysis
• Another Static Testing technique is static analysis, which is used
to contain the assessment of the code quality, which is established
by developers.
• We can use the different tools to perform the code's analysis and
evaluation of the same.
• In other words, we can say that developers' developed code is
analyzed with some tools for structural bugs, which might cause
the defects.
• The static analysis will also help us to identify the below errors:
• Dead code
• Unused variables
• Endless loops
• Incorrect syntax
• Variable with undefined value
• This is the systematic process of analyzing the source code of the software
without actually executing it. In this process, the source code for the
software is analyzed for different parameters, such as below:
• Whether or not the code meets the industry coding standards?
• Are there any loopholes in the dry run of the code?
• Is the syntax correct?
• Is the source code optimized or needs more optimizations?
• Is there any dead code or unreachable code?
• Are there any unassigned variables?
• Infinite loops present in the code.
Static Analysis is of three types:
• Data Flow:
Data flow is related to the stream processing.
• Control Flow:
Control flow is basically how the statements or instructions are
executed.
• Cyclomatic Complexity:
Cyclomatic complexity is the measurement of the complexity of the
program that is basically related to the number of independent paths in
the control flow graph of the program.
Control Flow Testing

• Control flow testing is a testing technique that comes under white box
testing. The aim of this technique is to determine the execution order
of statements or instructions of the program through a control
structure. The control structure of a program is used to develop a test
case for the program. In this technique, a particular part of a large
program is selected by the tester to set the testing path. It is mostly
used in unit testing. Test cases represented by the control graph of the
program.
• Control Flow Graph is formed from the node, edge, decision node,
junction node to specify all possible execution path.
Notations used for Control Flow Graph

1. Node
2. Edge
3. Decision Node
4. Junction node
 Node
• Nodes in the control flow graph are used to create a path of procedures.
Basically, it represents the sequence of procedures which procedure is next
to come so, the tester can determine the sequence of occurrence of
procedures.
• We can see below in example the first node represent the start procedure
and the next procedure is to assign the value of n after assigning the value
there is decision node to decide next node of procedure as per the value of n
if it is 18 or more than 18 so Eligible procedure will execute otherwise if it
is less than 18 Not Eligible procedure executes. The next node is the
junction node, and the last node is stop node to stop the procedure.
• Edge
• Edge in control flow graph is used to link the direction of nodes.
• We can see below in example all arrows are used to link the nodes in an
appropriate direction.
• Decision node
• Decision node in the control flow graph is used to decide next node of
procedure as per the value.
• We can see below in example decision node decide next node of procedure as
per the value of n if it is 18 or more than 18 so Eligible procedure will
execute otherwise if it is less than 18, Not Eligible procedure executes.
• Junction node
• Junction node in control flow graph is the point where at least three links
meet.
 Example
public class VoteEligiblityAge{
public static void main(String []args){
int n=45;
if(n>=18)
{
System.out.println("You are eligible for voting");
} else
{
System.out.println("You are not eligible for voting");
}
} }
Diagram - control flow graph
• The above example shows eligibility criteria of age for voting where if age
is 18 or more than 18 so print message "You are eligible for voting" if it is
less than 18 then print "You are not eligible for voting."
• Program for this scenario is written above, and the control flow graph is
designed for the testing purpose.
• In the control flow graph, start, age, eligible, not eligible and stop are the
nodes, n>=18 is a decision node to decide which part (if or else) will
execute as per the given value. Connectivity of the eligible node and not
eligible node is there on the stop node.
• Test cases are designed through the flow graph of the programs to
determine the execution path is correct or not. All nodes, junction, edges,
and decision are the essential parts to design test cases.
Cyclomatic complexity
• Cyclomatic complexity is a software metric used to measure the
complexity of a program.
• Thomas J. McCabe developed this metric in 1976.
• McCabe interprets a computer program as a set of a strongly
connected directed graph.
• Nodes represent parts of the source code having no branches and
arcs represent possible control flow transfers during program
execution.
• The notion of program graph has been used for this measure, and it
is used to measure and control the number of paths through a
program.
• The complexity of a computer program can be correlated with the
topological complexity of a graph.
 What is Cyclomatic Complexity?
• Cyclomatic complexity is a source code complexity measurement that is being
correlated to a number of coding errors.
• It is calculated by developing a Control Flow Graph of the code that measures
the number of linearly-independent paths through a program module.
• McCabe proposed the cyclomatic number, V (G) of graph theory as an
indicator of software complexity. The cyclomatic number is equal to the
number of linearly independent paths through a program in its graphs
representation. For a program control graph G, cyclomatic number, V (G), is
given as:
• Cyclomatic complexity(G) = E - N + 2*P
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points
 Example
IF A = 10 THEN
IF B > C THEN
A=B
ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C

The Cyclomatic complexity is calculated using the above control flow

diagram that shows seven nodes(shapes) and eight edges (lines), hence the
cyclomatic complexity is 8 - 7 + 2 = 3
 Example Method-01:

Cyclomatic Complexity
= Total number of closed regions in the control
1. { int i, j, k; flow graph + 1
2. for (i=0 ; i<=N ; i++) =3+1
3. p[i] = 1; =4

4. for (i=2 ; i<=N ; i++) Method-02:

{ Cyclomatic Complexity
5. k = p[i]; j=1; =E–N+2
= 16 – 14 + 2
6. while (a[p[j-1]] > a[k] { =4
7. p[j] = p[j-1];
8. j--; Method-03:
}
Cyclomatic Complexity
9. p[j]=k; =P+1
10. } =3+1
=4
Data flow testing
 Data flow testing
• Data flow testing is used to analyze the flow of data in the program.
• It is the process of collecting information about how the variables flow the
data in the program.
• It tries to obtain particular information of each particular point in the process.
• Data flow testing is a group of testing strategies to examine the control flow
of programs in order to explore the sequence of variables according to the
sequence of events.
• It mainly focuses on the points at which values assigned to the variables and
the point at which these values are used by concentrating on both points, data
flow can be tested.
• Data flow testing uses the control flow graph to detect illogical things
that can interrupt the flow of data.
• Anomalies in the flow of data are detected at the time of associations
between values and variables due to:
• If the variables are used without initialization.
• If the initialized variables are not used at least once.
• Data objects occurring in the programming life cycle goes through 3 phases
• Definition: data variables are defined, created and initialized, along with the
allocation of the memory to that particular data object.
• Usage:Declared data variables may be used in the programming code, in two
forms
• As the part of the predicate(P), such as "If (A>B)"
• In the computational form(C), when the data items are involved in the calculations to
give some output.
• Deletion or Kill:Memory allocated to the variables, gets freed and is put into
for some other use.
 What is Data Flow Testing?
• Data flow testing is a family of test strategies based on selecting paths through the
program's control flow in order to explore sequences of events related to the status of
variables or data objects.
• Dataflow Testing focuses on the points at which variables receive values and the
points at which these values are used.
• Data flow testing:
• The programmer can perform numerous tests on data values and variables. This type
of testing is referred to as data flow testing.
• It is performed at two abstract levels: static data flow testing and dynamic data flow
testing.
• The static data flow testing process involves analyzing the source code without
executing it.
• Static data flow testing exposes possible defects known as data flow anomaly.
• Dynamic data flow identifies program paths from source code.
 Types of data flow testing
1. Static data flow testing: The declaration, usage, and deletion of the variables
are examined without executing the code. A control flow graph is helpful in this.
• No actual execution of the code is carried out in Static Data Flow testing.
Generally, the definition, usage and kill pattern of the data variables is
scrutinized through a control flow graph.
2. Dynamic data flow testing: The variables and data flow are examined with
the execution of the code.
• The code is executed to observe the transitional results. Dynamic data flow
testing includes:
• Identification of definition and usage of data variables.
• Identifying viable paths between definition and usage pairs of data variables.
• Designing & crafting test cases for these paths.
 Data Flow Testing Coverage
• The coverage of data flow in terms of "sub-paths" and "complete path"
may be categorised under following types:

• All definition coverage: Covers "sub-paths" from each definition to some

of their respective use.
• All definition-C use coverage:"sub-paths" from each definition to all their
respective C use.
• All definition-P use coverage: "sub-paths" from each definition to all their
respective P use.
• All use coverage: Coverage of "sub-paths" from each definition to every
respective use irrespective of types.
• All definition use coverage: Coverage of "simple sub-paths" from each
definition to every respective use.
Example
• In this code, we have a total 8 statements, and we will choose a path which
covers all the 8 statements.
• As it is evident in the code, we cannot cover all the statements in a single
path because if statement 2 is true then statements 4, 5, 6, 7 not covered, and
if statement 4 is true then statement 2 and 3 are not covered.
• So, we are taking two paths to cover all the statements.
• 1. x= 1
• Path - 1, 2, 3, 8
• Output = 2
• When we set value of x as 1 first it come on step 1 to read and assign the
value of x (we took 1 in path) then come on statement 2 (x>0 (we took 2 in
path)) which is true and it comes on statement 3 (a= x+1 (we took 3 in path))
at last it comes on statement 8 to print the value of x (output is 2).
• For the second path, we take the value of x is 1
• 2. Set x= -1
• Path = 1, 2, 4, 5, 6, 5, 6, 5, 7, 8
• Output = 2
• When we set the value of x as ?1 then first, it comes on step 1 to read and assign
the value of x (we took 1 in the path) then come on step number 2 which is false
because x is not greater than 0 (x>0 and their x=-1).
• Due to false condition, it will not come on statement 3 and directly jump on
statement 4 (we took 4 in path) and 4 is true (x<=0 and their x is less than 0) then
come on statement 5 (x<1 (we took 5 in path)) which is also true so it will come on
statement 6 (x=x+1 (we took 6 in path)) and here x is incremented by 1.
• x=-1+1
• x=0
• There is value of x become 0. Now it goes to statement 5(x<1 (we took 5 in path))
with value 0 and 0 is less than 1 so, it is true. Come on statement 6 (x=x+1 (we
took 6 in path))
• x=x+1
• x= 0+1
• x=1
• There x has become 1 and again goes to statement 5 (x<1 (we took 5 in path)) and
now 1 is not less than 1 so, condition is false and it will come to else part means
statement 7 (a=x+1 where the value of x is 1) and assign the value to a (a=2). At
last, it come on statement 8 and print the value (Output is 2).
Make associations for the code:

• Associations
• In associations we list down all the definitions with all of its uses.
• (1, (2, f), x), (1, (2, t), x), (1, 3, x), (1, (4, t), x), (1, (4, f), x), (1, (5, t), x),
(1, (5, f), x), (1, 6, x), (1, 7, x), (6,(5, f)x), (6,(5,t)x), (6, 6, x), (3, 8, a), (7,
8, a).
How to make associations in data flow testing
<link>
• (1, (2, t), x), (1, (2, f), x)- This association is made with statement 1 (read x;) and
statement 2 (If(x>0)) where x is defined at line number 1, and it is used at line
number 2 so, x is the variable.
• Statement 2 is logical, and it can be true or false that's why the association is
defined in two ways; one is (1, (2, t), x) for true and another is (1, (2, f), x) for false.
• (1, 3, x)- This association is made with statement 1 (read x;) and statement 3 (a=
x+1) where x is defined in statement 1 and used in statement 3. It is a computation
use.
• (1, (4, t), x), (1, (4, f), x)- This association is made with statement 1 (read x;) and
statement 4 (If(x<=0)) where x is defined at line number 1 and it is used at line
number 4 so x is the variable. Statement 4 is logical, and it can be true or false that's
why the association is defined in two ways one is (1, (4, t), x) for true and another
is (1, (4, f), x) for false.
• (1, (5, t), x), (1, (5, f), x)- This association is made with statement 1 (read x;) and
statement 5 (if (x<1)) where x is defined at line number 1, and it is used at line
number 5, so x is the variable.
• Statement 5 is logical, and it can be true or false that's why the association is
defined in two ways; one is (1, (5, t), x) for true and another is (1, (5, f), x) for false.
• (1, 6, x)- This association is made with statement 1 (read x;) and statement 6 (x=x+1). x is
defined in statement 1 and used in statement 6. It is a computation use.
• (1, 7, x)- This association is made with statement 1 (read x) and statement 7 (a=x+1). x is
defined in statement 1 and used in statement 7 when statement 5 is false. It is a
computation use.
• (6, (5, f) x), (6, (5, t) x)- This association is made with statement 6 (x=x+1;) and statement
5 if (x<1) because x is defined in statement 6 and used in statement 5. Statement 5 is
logical, and it can be true or false that's why the association is defined in two ways one is
(6, (5, f) x) for true and another is (6, (5, t) x) for false. It is a predicted use.
• (6, 6, x)- This association is made with statement 6 which is using the value of variable x
and then defining the new value of x.
• x=x+1
• x= (-1+1)
• Statement 6 is using the value of variable x that is ?1 and then defining new value of x [x=
(-1+1) = 0] that is 0.
• (3, 8, a)- This association is made with statement 3(a= x+1) and statement 8 where variable
a is defined in statement 3 and used in statement 8.
• (7, 8, a)- This association is made with statement 7(a=x+1) and statement 8 where variable
a is defined in statement 7 and used in statement 8.
• Definition, c-use, p-use, c-use some p-use coverage, p-use some c-use coverage in data
flow testing <link>
• The next task is to group all the associations in Definition, c-use, p-use, c-use some p-use
coverage, p-use some c-use coverage categories.

• So, these are the all association which contain definition, Predicate use (p-use),
Computation use (c-use)

• (1, (2, f), x), (1, (2, t), x), (1, 3, x), (1, (4, t), x), (1, (4, f), x), (1, (5, t), x), (1, (5, f), x), (1,
6, x), (1, 7, x), (6,(5, f)x), (6,(5,t)x), (6, 6, x), (3, 8, a), (7, 8, a), (3, 8, a), (7, 8, a)
• Definition
• Definition of a variable is the occurrence of a variable when the value is
bound to the variable. In the above code, the value gets bound in the first
statement and then start to flow.

• If(x>0) is statement 2 in which value of x is bound with it.

• Association of statement 2 is (1, (2, f), x), (1, (2, t.)
• a= x+1 is statement 3 bounded with the value of x
• Association of statement 3 is (1, 3, x)
• All definitions coverage
• (1, (2, f), x), (6, (5, f) x), (3, 8, a), (7, 8, a).
• Predicate use (p-use)
• If the value of a variable is used to decide an execution path is considered as
predicate use (p-use). In control flow statements there are two
• Statement 4 if (x<=0) is predicate use because it can be predicate as true or false. If
it is true then if (x<1),6x=x+1; execution path will be executed otherwise, else path
will be executed.
• Computation use (c-use)
• If the value of a variable is used to compute a value for output or for defining
another variable.
• Statement 3 a= x+1 (1, 3, x)
Statement 7 a=x+1 (1, 7, x)
Statement 8 print a (3, 8, a), (7, 8, a).
• These are Computation use because the value of x is used to compute and value of
a is used for output.
• All c-use coverage
• (1, 3, x), (1, 6, x), (1, 7, x), (6, 6, x), (6, 7, x), (3, 8, a), (7, 8, a).
• All c-use some p-use coverage
• (1, 3, x), (1, 6, x), (1, 7, x), (6, 6, x), (6, 7, x), (3, 8, a), (7, 8, a).
• All p-use some c-use coverage
• (1, (2, f), x), (1, (2, t), x), (1, (4, t), x), (1, (4, f), x), (1, (5, t), x), (1, (5, f), x),
(6, (5, f), x), (6, (5, t), x), (3, 8, a), (7, 8, a).
• After collecting these groups, (By examining each point whether the variable
is used at least once or not) tester can see all statements and variables are
used. The statements and variables which are not used but exist in the code,
get eliminated from the code.
 Tools used for Static Testing
• Static code analysis can be performed either manually or automatically by
using tools. Some of the tools which can be used for static analysis of
code are:
1. Checkstyle
2. Clang
3. Sonarqube
4. Soot
5. Thread Safe
6. Source meter
7. Find Bugs
8. JTest
9. JArchitect
 Advantages of Static Testing
• Improved Product quality
Static testing will enhance the product quality because it identifies the flaws or
bugs in the initial stage of software development.
• Improved the efficiency of Dynamic testing
The usage of Static testing will improve Dynamic Testing efficiency because the
code gets cleaner and better after executing Static Testing.
As we understood above, static Testing needs some efforts and time to generate
and keep good quality test cases.
• Reduced SDLC cost
The Static Testing reduced the SDLC cost because it identifies the bugs in the
earlier stages of the software development life cycle. So, it needs less hard
work and time to change the product and fix them.
• Immediate evaluation & feedback
The static testing provides us immediate evaluation and
feedback of the software during each phase while developing
the software product.
• Exact location of bug is traced
When we perform the static testing, we can easily identify the
bugs' exact location compared to the dynamic Testing.
Software Inspection Checklist

• Definition: A Checklist is a catalog of items/tasks that are recorded

for tracking. This list could be either ordered in a sequence or could
be haphazard.
• Checklists are a part and parcel of our daily lives. We use them in
various situations from grocery shopping to having a to-do list for the
day’s activities.
• Some possible checks that can be made during the inspection process are given below:
• Data Faults :
• Check Are all of the variables of program initialized before their values are used?
• Has all constant been given name?
• Is there any chance of buffer overflow? Etc.
• Control Faults :
• Is the condition correct for each conditional statement?
• Is each loop certain to terminate?
• Are compound statements bracketed correctly or not?
• Input/Output (I/O) Faults :
• Are all of the input variables used or not?
• Are all of the output variables assigned to a value before they are output?
• Can input that are unexpected causes of corruption? Etc.
• Interface Faults :
• Does all method and functions have the correct number of parameters?
• Do the type of parameters i.e. actual and formal matches?
• Are the parameters present in the correct order?
• Do they have the same model of shared memory structure, if all of the components access shared memory?
• Storage Management Faults :
• Have all links been reassigned correctly, if a linked structure is modified?
• Has space been correctly allocated, if dynamic storage is used?
• Does the space get de-allocated explicitly after it is no longer required? Etc.
• Exception Management Faults :
• Do all possible error conditions been taken into account or consideration?
• Requirement Inspection Checklist :
• Do requirements exhibit a clear distinction among functions and data?
• Do requirements exactly define all the information that is needed to be displayed to users?
• Do requirements address system and user response to all conditions of error?
• Is each of the requirements stated clearly, concisely, and unambiguously?
• Is each of the requirements testable?
• Are there any ambiguous or implied requirements present?
• Are there any conflicting requirements?
• Are there areas that are not addressed in the Software Requirements Specification (SRS) that
is needed to be?
• Are performance requirements like response time, data storage requirements, etc. stated?
• Error Handling and Recovery Checklist :
• Is there any adequate error condition testing?
• Are error conditions tested where the probability of an error existing is high or results of an
error would be fatal to the system?
• Are all return codes documented?
• Are all return messages understandable?
• Does the program allow for successful error recovery; across module or process failures?
across operating system failure? across interrupts? across hardware failures?
-According to data collected from various studies, the
benefits of inspection include the following:
Net increase in productivity in the range of 30-100%;
Overall project time saving of 10-30%;
5 to 10 times reduction in test execution costs and time;
Reduction in maintenance costs of up to one order of magnitude;
Improvement in consequent product quality.
Minimal defect correction backlash at systems integration time.
-According to many previous studies inspection is more efficient than
testing, specifically when comparing inspection of code modules
with testing those modules.
Inspection finds most of the problems testing would find, and does so more
efficiently.

-But such enthusiasm should be tempered by the fact that some

subtle bugs may escape inspection, and could only be detected
through testing by executing the software code.
So, inspection and testing should be considered as complementary processe5s.
Inspection Participants and Procedure
Participants
-The following key participants are involved in a formal inspection
process:
Author (or Owner): the person who wrote the document or work product under
review; his role in the inspection consists solely of presenting his work, and helping
others understand it, but not of “defending” it.
Moderator: runs the inspection, by rigorously enforcing its purpose, which is to
discover deficiencies in the document being inspected.
Recorder: is in charge of recording possible deficiencies uncovered during the
inspection process, and along with the moderator, of preparing at the end of the
process, an inspection report, which will be used to fix the problems found.

Reader: Paraphrases the code or document at an inspection meeting.

Inspectors: are the ones who raise questions, suggest problems, and criticize
the document (but are not supposed to “attack” it). Inspectors may include people
from different expertise (e.g., quality assurance, marketing etc.), each bringing a
different viewpoint. 6
 Procedure
-All the participants are supposed to study the document in advance,
and identify issues to raise.
-Since often the same issues may come over and over, inspectors can
work from checklists of things to look for, lists to which they add as
their experience accumulates.
-Since code can be execution tested whereas other documents cannot,
any inspection program should start with the other documents.

-Formal inspections requires a minimum of four people and is best with

seven participants.
In small organizations, the personnel don’t exist to systematically carry it out.
In such case, if two engineers work well together, they can do useful inspection
with no moderator, and one of them acting as the recorder.

7
 Inspection Process

Planning: Identifies work product to be inspected, determines the size and composition
of the inspection team, and sets the inspection schedule.
Overview: Optional phase where team members who are unfamiliar with the work product
to be inspected receive orientation.
Preparation: Team members inspect the work individually looking for defects in the work
product with the guidance of relevant checklist.
-The majority of defects found in inspection processes are found in this stage (about 75%);
-The reviewer should record any issues found, and determine their severity (i.e., major or minor):
• major for a defect that will cause an observable product failure or departure from requirements;
• minor for a defect that will not cause a failure in execution of the product.
-At this stage, it is strictly required that reviewers work individually and do not attempt to find 8
solutions to defects found as this is an improper use of their time.
Inspection Process (ctd.)

Inspection Meeting: Inspection team members meet to discuss possible defects in the work
product. The moderator should ensure that all the issues raised by individual reviewers are
appropriately logged.
Rework: The work product is revised to conform to requirements and specifications.
Follow up: The rework is verified, final inspection data is collected and summarized, and the
inspection is officially closed. At this stage also, the moderator may calculate certain metrics
to assess the effectiveness of the inspection and recommend improvement to the inspection
process. 9
-Example of Individual Reviewer Log form (used during preparation stage)

10
 -Example of Log form (used during meeting phase)
Date: 14 March 2003
Team: D T 1
Part/Level: W C M S - H L D - 1 - 0 3 Cycle: 1
Moderator: M. Python Owner: M. Bean

Engineer Data

Na me Defects Preparation Data Est.

Major Minor Size Time Rate Yield
(Size Units) (minutes) (Size Units/hr)
J.B. 8 2 15 pages 60 minutes 15 pages/hr
R. M . 9 4 15 pages 75 minutes 12 pages/hr
Totals: 67.5 minutes 13.5 pages/hr

Defect Data

No. Defect Description Engineers

(finding ma j o r defects)
J.B. R. M.
1.01 T B D indicates incomplete specification 1 1
U C D Missing use case for adding resources to courses 1 1
U C D Extra use case “Check Enrolment” 1
U C D T e r m course used inconsistently 1
S D 4.3 M e s s a g e to list s t u d e n t s i n c o r r e c t l y p a s s e d to 1 1
instance of Student
S D 4.10 N a m e does not match U C D 1 1
S D 4.11 M e s s a g e to list c o u r s e s i n c o r r e c t l y p a s s e d to 1 1
instance of Course
S D M essage to ad d assessment item used inconsistently 1
4.14/4.15
SD4.23 Sequence diagram describes interaction not defined 1 1
in requirements – n o corresponding use case
SD4.24 Sequence diagram describes interaction not defined 1 1
in requirements – n o corresponding use case
SD4.25 Missing alternate for ch eck weighting 1 1

Totals: 8 9
Uni que Defects: 2 3
Inspection S u m m a r y Product Size: 15 Size Measure: pages
Total Defects for J.B: 8 Total Defects for R . M : 9 C o m m o n Defects:
6
Est. Total Defects: Total N u m b e r Found: N u m b e r Left:

Meeting Time: 30 min Total Insp. Hours: Overall Rate:

11
M a j o r Defects/Total: Defects / Size Unit: Defects / Hour
Inspection Workload
-The amount of code which can be inspected in a given time depends
on the experience of the inspection team, the programming language
and the application domain.
-Measurement data collected at IBM, and confirmed by AT&T led
to the following observations:
1. About 500 source code statements per hour can be considered during the
overview stage.
2. During individual preparation, about 125 source code statements per hour can
be examined.
3. From 90 to 125 statements per hour can be inspected during the meeting.

-It was suggested that the maximum time spent on an inspection

should be about two hours as the efficiency of the defect detection
process falls off after that time.
Inspection should therefore be a frequent process, carried out on relatively small
software components, during program development (1-2 hours prep + 1h 1m2eeting)
 4. Inspection Checks
-The inspection process should always be driven by a checklist of
common programming errors.
This should be established by discussion with experienced staff and regularly
updated as more experience is gained of the inspection process.
Different checklist should be prepared for different programming languages.
Possible checks which can be made during the inspection include:
Fault class Inspection Check
Data Faults Are all program variables initialized before their values are used? Have all constant
been named? Is there any possibility of buffer overflow? Etc.
Control Faults For each conditional statement, is the condition correct? Is each loop certain to
terminate? Are compound statements correctly bracketed? Etc.
Input/output faults Are all input variables used? Are all output variables assigned a value before they are
output? Can unexpected inputs cause corruption? Etc.
Interface faults Do all function and method calls have the correct number of parameters? Do formal
and actual parameter types match? Are the parameter in right order? If components
access shared memory, do they have the same model of the shared memory structure?
Storage management faults If a linked structure is modified, have all links been correctly reassigned? If dynamic
storage is used, has space been allocated correctly? Is space explicitly de-allocated
after it is no longer required? Etc.
Exception management faults Have all possible error conditions been taken into account? 13
Sample Inspection Checklists
Requirements Inspection Checklist
1. Do requirements exhibit a clear distinction between functions and data?
2. Do requirements define all the information to be displayed to users?
3. Do requirements address system and user response to error conditions?
4. Is each requirement stated clearly, concisely, and unambiguously?
5. Is each requirement testable?
6. Are there ambiguous or implied requirements?
7. Are there conflicting requirements?
8. Are there areas not addressed in the Software Requirements Specification (SRS) that need to be?
9. Are performance requirements (such as response time, data storage requirements) stated?

Sample Design Inspection Checklist Questions

(Error Handling and Recovery)
1. Is there adequate error condition testing?
2. Are error conditions tested where the probability of an error is
high or results of an error would be fatal to the system?
3. Are return codes documented?
4. Are return messages understandable?
5. Does the program allow for successful error recovery...
- across module or process failures?
- across operating system failure?
- across interrupts?
- across hardware failures? 14
(Java) Code Inspection Checklist

1. Variable and Constant Declaration Defects (VC)

1. Are descriptive variable and constant names used in accord with naming conventions?
2. Are there variables with confusingly similar names?
3. Is every variable properly initialized?
4. Could any non-local variables be made local?
5. Are there literal constants that should be named constants?
6. Are there macros that should be constants?
7. Are there variables that should be constants?

2. Function Definition Defects (FD)

8. Are descriptive function names used in accord with naming conventions?
9. Is every function parameter value checked before being used?
10. For every function: Does it return the correct value at every function return point?

3. Class Definition Defects (CD)

11. Does each class have an appropriate constructor and destructor?
12. For each member of every class: Could access to the member be further restricted?
13. Do any derived classes have common members that should be in the base class?
14. Can the class inheritance hierarchy be simplified?

15
 5. Inspection Metrics
-The data collected during a software process are used to compute a set
of metrics that support evaluation and improvement of the process as
well as planning and tracking quality.
-The metrics computed during such process should be defined by the
requirements of your organization (typically in the quality manual).
The collection of data and calculation of metrics for no reason is a waste of time.

-Many different metrics can be calculated during an inspection

process including the following:
• The number of major and minor defects found
• The number of major defects found to total found. (If the proportion of minor defects to
major defects is too large a moderator may request that the reviewer repeat the review, focusing
on major defects, prior to commencing the logging meeting)

•The size of the artifact (pages, LOC, ...)

•The rate of review - the size of the reviewed artifact divided by time (normally expressed in
hours) (e.g., 15 pages /hour). 16
•The defect detection rate - the number of major defects found per review hour.
Total Number of Defects Found and Defects Density
-Total number of defects found is the sum of the total number of defects
found by each reviewer, minus the number of common defects found.
For instance, with 2 reviewers, the metric is computed by

Total Defects Found = A + B - C

Where A and B are the number found by reviewer A and B respectively and C is
the number found by both A and B.

-Defect density is the ratio of the number of defects found to the size
of the artifact. It is given by

Defect Density = Total Defects Found / Size

Where the size of the artifact is measured in number of pages, loc, or other size measure.

17
Example: compute inspection metrics from the following inspection log form
Team: D T 1
Date: 14 March 2003

Part/Level: W C M S - H L D - 1 - 0 3 Cycle: 1
Moderator: M. Python Owner: M. Bean

Engineer Data

Na me Defects Preparation Data Est.

Major Minor Size Time Rate Yield
(Size Units) (minutes) (Size Units/hr)
J.B. 8 2 15 pages 60 minutes 15 pages/hr
R. M . 9 4 15 pages 75 minutes 12 pages/hr
Totals: 67.5 minutes 13.5 pages/hr

Defect Data

No. Defect Description Engineers

(finding ma j o r defects)
J.B. R. M.
1.01 T B D indicates incomplete specification 1 1
U C D Missing use case for adding resources to courses 1 1
U C D Extra use case “Check Enrolment” 1
U C D T e r m course used inconsistently 1
S D 4.3 M e s s a g e to list s t u d e n t s i n c o r r e c t l y p a s s e d to 1 1
instance of Student
S D 4.10 N a m e does not match U C D 1 1
S D 4.11 M e s s a g e to list c o u r s e s i n c o r r e c t l y p a s s e d to 1 1
instance of Course
S D M essage to ad d assessment item used inconsistently 1
4.14/4.15
SD4.23 Sequence diagram describes interaction not defined 1 1
in requirements – n o corresponding use case
SD4.24 Sequence diagram describes interaction not defined 1 1
in requirements – n o corresponding use case
SD4.25 Missing alternate for ch eck weighting 1 1

Totals: 8 9
Uni que Defects: 2 3
Inspection S u m m a r y Product Size: 15 Size Measure: pages
Total Defects for J.B: 8 Total Defects for R . M : 9 C o m m o n Defects:
6
Est. Total Defects: Total N u m b e r Found: N u m b e r Left:

Meeting Time: 30 min Total Insp. Hours: Overall Rate:

18
M a j o r Defects/Total: Defects / Size Unit: Defects / Hour
 Estimated Total Number of Defects
-The estimated total number of defects is the sum of the total number
of defects found and the estimated total number of defects remaining.
In order to estimate the total number of defects remaining in an artifact immediately
after inspection, we use an approach similar to the population sampling approach
used by biologists to estimate the population of a particular ecosystem.

Population Sampling Approach

-Suppose we have a fish farm and we want to estimate the total
number of fish we have. We could apply the capture-recapture method:
1. Capture a number of fish, tag them and release them (let this number be S1).
2. Allow time for the first sample population to redistribute.
3. Capture a second number of fish (let this number be S2).
4. Count the number of tagged fish in the second population (let this number be ST).
5. Calculate the proportion of tagged fish in the second population (let this number be T,
then T= ST/ S2).
6. We assume that T is representative of the proportion of tagged fish in the total
population (POP), so TPOP= S1, or for our purposes POP= S1 /T.
19
-Using the population sampling approach to estimate
the number of defects remaining leads to the following
steps:
Let the number of defects found by one reviewer be the tagged population (A).

1. Assume an even likelihood of finding all defects (even distribution,...)

2. Count the number of defects found by the second reviewer (B).
3. Count the number of defects found by the second reviewer that were also found by the
first (C the common defects).
4. Calculate the proportion of common defects in the second reviewers defects (T=C/B).
5. We assume that T is representative of the proportion of common defects in the total
number of defects (EstTot), so T EstTot=A, or for our purposes
EstTot = A/T = (A B)/C.

-So assuming that defects are equally likely to be found in an artifact

and each reviewer is equally likely to find every defect, then:
Estimated Total Defects = (A B)/C

Note that in practice such assumptions are not always fulfilled, simply because some
defects are harder to find than others, and some reviewers are better than others.
20
Inspection Yield
-Inspection yield refers to the defect removal efficiency (DRE) of an
inspection process.

-The defect removal efficiency of a process is given by calculating

the percentage of total defects that were found by that process. So
the yield of an inspection is given by:

Yield = Total Defects Found / Estimated Total Defects 100%

21
Inspection Rate and
Defect Detection Rate
-Requires computing the inspection time, which is the sum of each
reviewers review time plus the total person time spent in each meeting.
-The inspection rate is computed by:

Inspection rate = size / total inspection time

Where:
size stands for the size of the artifact in number of pages, loc, or other size measure.
total inspection time measured in hours

-The defect detection rate is computed by:

Defect finding efficiency = Total defects found / total inspection time

22
Calculating Inspection Metrics with
more than two Reviewers

-If there are more than 2 reviewers, the same approach can be taken
to calculate inspection totals and yield by grouping reviewers into
two groups for calculation: group A and group B:

If there are 3 reviewers, it is often a good idea to choose the person who has the most
unique defects to be one group and the other two reviewers to be the other group. For
each group if any member of that group has found a defect, then count it for the group.

23
Example with 3 reviewers:
No. Defect Description Engineers (finding major defects)

R1 R2 R3 A (R2) B
1 1 1

1 1
1 1
1 1 1
1 1 1
1 1
1 1
1
1
1
1 1 1

Totals 7 9 7
Unique defects 1 2 0

Inspection Summary Product size: 10 Size measure: pages

Total defects for A: Total defects for B: Common defects: 24
Est. total defects: Total number found: Number left: