188 Software Testing: Principles and Practices

Chapter

6
Static Testing

OBJECTIVES We have discussed dynamic testing techniques that

execute the software being built with a number of
After reading this chapter, you should be able to
understand:
test cases. However, it suffers from the following
Static testing is complementary to
drawbacks:
dynamic testing Dynamic testing uncovers the bugs at a later
Static testing also improves the software stage of SDLC and hence is costly to debug.
quality
Dynamic testing is expensive and time-consum-
Some bugs can be detected only
through static testing
ing, as it needs to create, run, validate, and main-
Three types of static testing: Inspection,
tain test cases.
Walkthroughs, and Reviews The efficiency of code coverage decreases with
Inspections are the most widely used the increase in size of the system.
technique for static testing which is a
formal process to detect the bugs early
Dynamic testing provides information about
Benefits and effectiveness of inspection
bugs. However, debugging is not always easy. It
process is difficult and time-consuming to trace a failure
Variants of inspection process from a test case back to its root cause.
Walkthrough is a less formal and Dynamic testing cannot detect all the potential
less rigorous method as compared to bugs.
inspection process
Review is a higher level technique as
While dynamic testing is an important aspect of
compared to inspection or walkthrough, any quality assurance program, it is not a universal
as it also includes management remedy. Thus, it alone cannot guarantee defect-
representatives free product, nor can it ensure a sufficiently high
level of software quality.
In response to the above discussion, static testing is a complimentary tech-
nique to dynamic testing technique to acquire higher quality software. Static
testing techniques do not execute the software and they do not require the bulk
of test cases. This type of testing is also known as non-computer based testing
or human testing. All the bugs cannot be caught alone by the dynamic testing
technique; static testing reveals the errors which are not shown by dynamic
testing. Static testing can be applied for most of the verification activities dis-
 Static Testing 189l

cussed earlier. Since verification activities are required at every stage of SDLC
till coding, static testing also can be applied at all these phases.
Static testing techniques do not demonstrate that the software is operational
or that one function of software is working; rather they check the software
product at each SDLC stage for conformance with the required specifications
or standards. Requirements, design specifications, test plans, source code,
user’s manuals, maintenance procedures are some of the items that can be
statically tested.
Static testing has proved to be a cost-effective technique of error detec-
tion. An empirical comparison between static and dynamic testing [26, 27],
proves the effectiveness of static testing. Further, Fagan [28] reported that
more than 60% of the errors in a program can be detected using static testing.
Another advantage of static testing is that it provides the exact location of a
bug, whereas dynamic testing provides no indication of the exact source code
location of the bug. In other words, we can say that static testing finds the in-
process errors before they become bugs.
Static testing techniques help to produce a better product. Given below are
some of the benefits of adopting a static testing approach:
As defects are found and fixed, the quality of the product increases.
A more technically correct base is available for each new phase of
development.
The overall software life cycle cost is lower, since defects are found
early and are easier and less expensive to fix.
The effectiveness of the dynamic test activity is increased and less time
needs to be devoted for testing the product.
Immediate evaluation and feedback to the author from his/her peers
which will bring about improvements in the quality of future products.
The objectives of static testing can be summarized as follows:
To identify errors in any phase of SDLC as early as possible
To verify that the components of software are in conformance with its
requirements
To provide information for project monitoring
To improve the software quality and increase productivity

Types of Static Testing

Static testing can be categorized into the following types:
Software inspections
Walkthroughs
Technical reviews
190 Software Testing: Principles and Practices

6.1 INSPECTIONS
Software inspections were first introduced at IBM by Fagan in the early 1970s
[43]. These can be used to tackle software quality problems because they
allow the detection and removal of defects after each phase of the software
development process. Inspection process is an in-process manual examina-
tion of an item to detect bugs. It may be applied to any product or partial
product of the software development process, including requirements, design
and code, project management plan, SQA plan, software configuration plan
(SCM plan), risk management plan, test cases, user manual, etc. Inspections
are embedded in the process of developing products and are done in the early
stages of each product’s development.
This process does not require executable code or test cases. With inspec-
tion, bugs can be found on infrequently executed paths that are not likely to
be included in test cases. Software inspection does not execute the code, so
it is machine-independent, requires no target system resources or changes to
the program’s operational behaviour, and can be used much before the target
hardware is available for dynamic testing purposes.
The inspection process is carried out by a group of peers. The group of
peers first inspect the product at the individual level. After this, they discuss
the potential defects of the product observed in a formal meeting. The sec-
ond important thing about the inspection process is that it is a formal process
of verifying a software product. The documents which can be inspected are
SRS, SDD, code, and test plan.
An inspection process involves the interaction of the following elements:
Inspection steps
Role for participants
Item being inspected
The entry and exit criteria are used to determine whether an item is ready
to be inspected. Entry criteria mean that the item to be inspected is mature
enough to be used. For example, for code inspection, the entry criterion is
that the code has been compiled successfully. Exit criterion is that once the
item has been given for inspection, it should not be updated, otherwise it will
not know how many bugs have been reported and corrected through the
inspection process and the whole purpose of the inspection is lost.

6.1.1 INSPECTION TEAM

For the inspection process, a minimum of the following four team members
are required.
Author/Owner/Producer A programmer or designer responsible for producing
the program or document. He is also responsible for fixing defects discovered
during the inspection process.
 Static Testing 191l

Inspector A peer member of the team, i.e. he is not a manager or supervisor. He

is not directly related to the product under inspection and may be concerned
with some other product. He finds errors, omissions, and inconsistencies in
programs and documents.
Moderator A team member who manages the whole inspection process. He
schedules, leads, and controls the inspection session. He is the key person with
the responsibility of planning and successful execution of the inspection.
Recorder One who records all the results of the inspection meeting.

6.1.2 INSPECTION PROCESS

A general inspection process (see Fig. 6.1) has the following stages [29,14]:

Plan for the

Planning inspection
meeting

Define purpose
of the
Overview inspection
meeting

Team members
Individual
identify
preparation
potential errors

Item is
Inspection inspected in the
meeting inspection
meeting

Bugs which are

reported in the
Rework inspection
meeting are
fixed

Follow-up Planning and

overview

Figure 6.1 Inspection process

192 Software Testing: Principles and Practices

Planning During this phase, the following is executed:

The product to be inspected is identified.
A moderator is assigned.
The objective of the inspection is stated, i.e. whether the inspection is
to be conducted for defect detection or something else. If the objective
is defect detection, then the type of defect detection like design error,
interface error, code error must be specified. The aim is to define an ob-
jective for the meeting so that the effort spent in inspections is properly
utilized.
During planning, the moderator performs the following activities:
Assures that the product is ready for inspection
Selects the inspection team and assigns their roles
Schedules the meeting venue and time
Distributes the inspection material like the item to be inspected, check-
lists, etc.
Overview In this stage, the inspection team is provided with the background
information for inspection. The author presents the rationale for the product,
its relationship to the rest of the products being developed, its function and
intended use, and the approach used to develop it. This information is necessary
for the inspection team to perform a successful inspection.
The opening meeting may also be called by the moderator. In this meeting,
the objective of inspection is explained to the team members. The idea is that
every member should be familiar with the overall purpose of the inspection.
Individual preparation After the overview, the reviewers individually prepare
themselves for the inspection process by studying the documents provided
to them in the overview session. They point out potential errors or problems
found and record them in a log. This log is then submitted to the moderator.
The moderator compiles the logs of different members and gives a copy of this
compiled list to the author of the inspected item.
The inspector reviews the product for general problems as well as those
related to their specific area of expertise. Checklists are used during this
stage for guidance on typical types of defects that are found in the type of
product being inspected. The product being inspected is also checked against
standard documents to assure compliance and correctness. After reviewing,
the inspectors record the defects found on a log and the time spent during
preparation. Completed preparation logs are submitted to the moderator
prior to the inspection meeting.
 Static Testing 193l

The moderator reviews the logs submitted by each inspector to determine

whether the team is adequately prepared. The moderator also checks for trou-
ble spots that may need extra attention during inspection, common defects
that can be categorized quickly, and the areas of major concern. If the logs
indicate that the team is not adequately prepared, the moderator should re-
schedule the inspection meeting. After this, the compiled log file is submitted
to the author.
Inspection meeting Once all the initial preparation is complete, the actual
inspection meeting can start. The inspection meeting starts with the author of
the inspected item who has created it. The author first discusses every issue
raised by different members in the compiled log file. After the discussion, all
the members arrive at a consensus whether the issues pointed out are in fact
errors and if they are errors, should they be admitted by the author. It may be
possible that during the discussion on any issue, another error is found. Then,
this new error is also discussed and recorded as an error by the author.
The basic goal of the inspection meeting is to uncover any bug in the item.
However, no effort is made in the meeting to fix the bug. It means that bugs
are only being notified to the author, which he will fix later. If there is any
clarification regarding these bugs, then it should be asked or discussed with
other members during the meeting.
Another fact regarding the inspection is that the members of the meeting
should be sensitive to the feelings of the author. The author should not
be attacked by other members such that the author feels guilty about the
product. Every activity in the meeting should be a constructive engagement
so that more and more bugs can be discovered. It is the duty of the moderator
that the meeting remains focused towards its objective and the author is not
discouraged in any way.
At the end, the moderator concludes the meeting and produces a summary
of the inspection meeting. This summary is basically a list of errors found in
the item that need to be resolved by the author.
Rework The summary list of the bugs that arise during the inspection meeting
needs to be reworked by the author. The author fixes all these bugs and reports
back to the moderator.
Follow-up It is the responsibility of the moderator to check that all the
bugs found in the last meeting have been addressed and fixed. He prepares
a report and ascertains that all issues have been resolved. The document is
then approved for release. If this is not the case, then the unresolved issues
are mentioned in a report and another inspection meeting is called by the
moderator.
194 Software Testing: Principles and Practices

6.1.3 BENEFITS OF INSPECTION PROCESS

Bug reduction The number of bugs is reduced through the inspection process.
L.H. Fenton [86] reported that through the inspection process in IBM, the
number of bugs per thousand lines of code has been reduced by two-thirds.
Thus, inspection helps reduce bug injection and detection rates. According to
Capers Jones, ‘Inspection is by far the most effective way to remove bugs.’
Bug prevention Inspections can also be used for bug prevention. Based on
the experiences of previous inspections, analysis can be made for future
inspections or projects, thereby preventing the bugs which have appeared
earlier. Programmers must understand why bugs appear and what can be done
to avoid them in future. At the same time, they should provide inspection
results to the quality assurance team.
Productivity Since all phases of SDLC may be inspected without waiting
for code development and its execution, the cost of finding bugs decreases,
resulting in an increase in productivity. Moreover, the errors are found at their
exact places, therefore reducing the need of dynamic testing and debugging.
In the article by Fagan [43], an increase of 23% in coding productivity and a
25% reduction in schedules were reported.
Real-time feedback to software engineers The inspections also benefit software
engineers/developers because they get feedback on their products on a relatively
real-time basis. Developers find out the type of mistakes they make and what is
the error density. Since they get this feedback in the early stages of development,
they may improve their capability. Thus, inspections benefit software engineers/
developers in the sense that they can recognize their weakness and improve
accordingly, which in turn benefits the cost of the project.
Reduction in development resource The cost of rework is surprisingly high if
inspections are not used and errors are found during development or testing.
Therefore, techniques should be adopted such that errors are found and fixed as
close to their place of origin as possible. Inspections reduce the effort required
for dynamic testing and any rework during design and code, thereby causing
an overall net reduction in the development resource. Without inspections,
more resources may be required during design and dynamic testing. But, with
inspection, the resource requirement is greatly reduced.
Quality improvement We know that the direct consequence of testing is improve-
ment in the quality of software. The direct consequence of static testing also
results in the improvement of quality of the final product. Inspections help to
improve the quality by checking the standard compliance, modularity, clarity,
and simplicity.
 Static Testing 205l

cases, which are documented in requirements specification. Since use-cases

are the basis of inspection, the focus is on finding functional defects, which are
relevant from the users’ point of view.
Abstraction driven reading This method given by Dunsmore et al. [99,100,101]
is designed for code inspections. In this method, an inspector reads a sequence
of statements in the code and abstracts the functions these statements compute.
An inspector repeats this procedure until the final function of the inspected
code artifact has been abstracted and can be compared to the specification.
Thus, the inspector creates an abstraction level specification based on the code
under inspection to ensure that the inspector has really understood the code.
Task-driven reading This method is also valid for code inspections proposed
by Kelly & Shepard [102]. In this method, the inspector has to create a data
dictionary, a complete description of the logic and a cross-reference between
the code and the specifications.
Function-point based scenarios This is based on scenarios for defect detection
in requirements documents [103]. This approach is based on function-point
analysis (FPA). FPA defines a software system in terms of its inputs, files,
inquiries, and outputs. The scenarios designed around function-points are
known as function-point scenarios. It consists of questions and directs the focus of
an inspector to a specific function-point item within the inspected requirements
document.

6.1.8 CHECKLISTS FOR INSPECTION PROCESS

The inspection team must have a checklist against which they detect er-
rors. The checklist is according to the item to be inspected. For example, the
design document and the code of the module should have different checklists.
Checklists can be prepared with the points mentioned in the verification of
each phase. Checklists should be prepared in consultation with experienced
staff and regularly updated as more experience is gained by the inspection
process.
The checklist may vary according to the environment and needs of the
organization. Each organization should prepare its own checklists for every
item.

6.2 STRUCTURED WALKTHROUGHS

The idea of structured walkthroughs was proposed by Yourdon [106]. It is a less
formal and less rigorous technique as compared to inspection. The common
term used for static testing is inspection but it is a very formal process. If you
206 Software Testing: Principles and Practices

want to go for a less formal process having no bars of organized meeting, then
walkthroughs are a good option.
A typical structured walkthrough team consists of the following members:
Coordinator Organizes, moderates, and follows up the walkthrough
activities.
Presenter/Developer Introduces the item to be inspected. This
member is optional.
Scribe/Recorder Notes down the defects found and suggestion pro-
posed by the members.
Reviewer/Tester Finds the defects in the item.
Maintenance Oracle Focuses on long-term implications and future
maintenance of the project.
Standards Bearer Assesses adherence to standards.
User Representative/Accreditation Agent Reflects the needs and
concerns of the user.
Walkthroughs differ significantly from inspections. An inspection is a six-
step, rigorous, formalized process. The inspection team uses the checklist
approach for uncovering errors. A walkthrough is less formal, has fewer steps
and does not use a checklist to guide or a written report to document the team’s
work. Rather than simply reading the program or using error checklists, the
participants ‘play computer’. The person designated as a tester comes to the
meeting armed with a small set of paper test cases—representative sets of
inputs and expected outputs for the program or module. During the meeting,
each test case is mentally executed. That is, the test data are walked through
the logic of the program. The state of the program is monitored on a paper
or any other presentation media. The walkthrough should have a follow-up
process similar to that described in the inspection process. The steps of a
walkthrough process are shown in Fig. 6.7.

Rework and
Organization Preparation Walkthrough
Follow-up

Figure 6.7 Walkthrough process

6.3 TECHNICAL REVIEWS

A technical review is intended to evaluate the software in the light of develop-
ment standards, guidelines, and specifications and to provide the management
with evidence that the development process is being carried out according to
 Static Testing 207l

the stated objectives. A review is similar to an inspection or walkthrough,

except that the review team also includes management. Therefore, it is con-
sidered a higher-level technique as compared to inspection or walkthrough.
A technical review team is generally comprised of management-level rep-
resentatives and project management. Review agendas should focus less on
technical issues and more on oversight than an inspection. The purpose is to
evaluate the system relative to specifications and standards, recording defects
and deficiencies. The moderator should gather and distribute the documenta-
tion to all team members for examination before the review. He should also
prepare a set of indicators to measure the following points:
Appropriateness of the problem definition and requirements
Adequacy of all underlying assumptions
Adherence to standards
Consistency
Completeness
Documentation
The moderator may also prepare a checklist to help the team focus on
the key points. The result of the review should be a document recording the
events of the meeting, deficiencies identified, and review team recommenda-
tions. Appropriate actions should then be taken to correct any deficiencies
and address all recommendations.

SUMMARY
Static testing techniques are not as popular as dynamic testing techniques. However, research-
ers have found static testing to be an effective aid in finding and preventing the defects at an
early stage. In recent years, due to the importance of early testing, these techniques are finding
their place in industries.
This chapter introduces static testing as a complementary technique to dynamic testing.
Static testing reveals the bugs which cannot be detected by dynamic testing. We have taken
three categories of static testing, namely inspection, walkthroughs, and reviews, and distin-
guished them. Inspection process is a widely used term for static testing. A lot of terminologies
are used interchangeably for static testing.
We have discussed every aspect of inspection process including the team members and the
inspection process. Moreover, in the literature, many variants of this process are also available.
These variants have also been discussed.
Let us review the important concepts discussed in this chapter:
The inspection process is a formal in-process manual examination of an item to detect
bugs. It may be applied to any product or partial product of the software development
process. This process is carried out by a group of peers with the help of checklists.