Chapter Three Static Techniques

Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim
Riau
ELVIRA MUNANDA

CHAPTER THREE
Static techniques
Static test techniques provide a powerful way to improve the
quality and productivity of software development. This chapter
describes static test techniques, including reviews, and provides an
overview of how they are conducted. The fundamental objective of
static testing is to improve the quality of software work products by
assisting engineers to recognize and fix their own defects early in the
software development process. While static testing techniques will not
solve all the problems, they are enormously effective. Static techniques
can improve both quality and productivity by impressive factors. Static
testing is not magic and it should not be considered a replacement for
dynamic testing, but all software organizations should consider using
reviews in all major aspects of their work including requirements,
design, implementation, testing, and maintenance. Static analysis tools
implement automated checks, e.g. on code.

REVIEWS AND THE TEST PROCESS
1 Recognize software work products that can be examined by different static
techniques. (K1)
2 Describe the importance and value of considering static techniques for the assessment
of software work products. (K2)
3 Explain the difference between static and dynamic techniques. (K2)
In Chapter 1, several testing terms were presented. Also testing itself was defined.
The latter definition is repeated here as a means for explaining the two major types of testing.
The definition of testing outlines objectives that relate to evaluation, revealing defects and
quality. As indicated in the definition two approaches can be used to achieve these objectives,
static testing and dynamic testing.
With dynamic testing methods, software is executed using a set of input values and its
output is then examined and compared to what is expected. During static testing, software
work products are examined manually, or with a set of tools, but not executed. As a
consequence, dynamic testing can only be applied to software code. Dynamic execution is
applied as a technique to detect defects and to determine quality attributes of the code. This
testing option is not applicable for the majority of the software work products. Among the
questions that arise are: How can we evaluate or analyze a requirements document, a design
document, a test plan, or a user manual? How can we effectively pre-examine the source code
before execution? One powerful technique that can be used is static testing, e.g. reviews. In
principle all software work products can be tested using review techniques.

Dynamic testing and static testing are complementary methods, as they tend to find
different types of defects effectively and efficiently. Types of defects that are easier to find
during static testing are: deviations from standards, missing requirements, design defects, non-
maintainable code and inconsistent interface specifications. Note that in contrast to dynamic
testing, static testing finds defects rather than failures.
In addition to finding defects, the objectives of reviews are often also informational,
communicational and educational, whereby participants learn about the content of software
work products to help them understand the role of their own work and to plan for future stages
of development. Reviews often represent project milestones, and support the establishment of
a baseline for a software product. The type and quantity of defects found during reviews can
also help testers focus their testing and select effective classes of tests. In some cases
customers/users attend the review meeting and provide feedback to the development team, so
reviews are also a means of customer/user communication.

Studies have shown that as a result of reviews, a significant increase in productivity
and product quality can be achieved [Gilb and Graham, 1993], [van Veenendaal, 1999].
Reducing the number of defects early in the product life cycle also means that less time has to
be spent on testing and maintenance. To summarize, the use of static testing, e.g. reviews, on
software work products has various advantages:
 Since static testing can start early in the life cycle, early feedback on quality issues can
be established, e.g. an early validation of user requirements and not just late in the life
cycle during acceptance testing.
 By detecting defects at an early stage, rework costs are most often relatively low and
thus a relatively cheap improvement of the quality of software products can be
achieved.
 Since rework effort is substantially reduced, development productivity figures are likely
to increase.
 The evaluation by a team has the additional advantage that there is an exchange of
information between the participants.
 Static tests contribute to an increased awareness of quality issues.
In conclusion, static testing is a very suitable method for improving the quality of
software work products. This applies primarily to the assessed products themselves, but it is
also important that the quality improvement is not achieved once but has a more structural
character. The feedback from the static testing process to the development process allows for
process improvement, which supports the avoidance of similar errors being made in the future.

REVIEW PROCESS
 1 Recall the phases, roles and responsibilities of a typical formal review. (K1)
 2 Explain the differences between different types of review: informal review, technical
review, walkthrough and inspection. (K2)
 3 Explain the factors for successful performance of reviews. (K2)
Reviews vary from very informal to formal (i.e. well structured and regulated).
Although inspection is perhaps the most documented and formal review technique, it is
certainly not the only one. The formality of a review process is related to factors such as the
maturity of the development process, any legal or regulatory requirements or the need for an
audit trail. In practice the informal review is perhaps the most common type of review. Informal
reviews are applied at various times during the early stages in the life cycle of a document. A
two-person team can conduct an informal review, as the author can ask a colleague to review a
document or code. In later stages these reviews often involve more people and a meeting. This
normally involves peers of the author, who try to find defects in the document under review and
discuss these defects in a review meeting. The goal is to help the author and to improve the
quality of the document. Informal reviews come in various shapes and forms, but all have one
characteristic in common – they are not documented.

Phases of a formal review
In contrast to informal reviews, formal reviews follow a formal process. A typical formal
review process consists of six main steps:
1 Planning
2 Kick-off
3 Preparation
4 Review meeting
5 Rework
6 Follow-up.
Planning
The review process for a particular review begins with a 'request for review' by the
author to the moderator (or inspection leader). A moderator is often assigned to take care of
the scheduling (dates, time, place and invitation) of the review. On a project level, the project
planning needs to allow time for review and rework activities, thus providing engineers with
time to thoroughly participate in reviews. For more formal reviews, e.g. inspections, the
moderator always performs an entry check and defines at this stage formal exit criteria. The
entry check is carried out to ensure that the reviewers' time is not wasted on a document that is
not ready for review. A document containing too many obvious mistakes is clearly not ready to
enter a formal review process and it could even be very harmful to the review process. It would
possibly de-motivate both reviewers and the author. Also, the review is most likely not effective
because the numerous obvious and minor defects will conceal the major defects.

Kick-off
An optional step in a review procedure is a kick-off meeting. The goal of this meeting
is to get everybody on the same wavelength regarding the document under review and to
commit to the time that will be spent on checking. Also the result of the entry check and
defined exit criteria are discussed in case of a more formal review. In general a kick-off is highly
recommended since there is a strong positive effect of a kick-off meeting on the motivation of
reviewers and thus the effectiveness of the review process. At customer sites, we have
measured results up to 70% more major defects found per page as a result of performing a
kick-off, [van Veenendaal and van der Zwan, 2000]

Preparation
The participants work individually on the document under review using the
related documents, procedures, rules and checklists provided. The individual participants
identify defects, questions and comments, according to their understanding of the
document and role. All issues are recorded, preferably using a logging form. Spelling
mistakes are recorded on the document under review but not mentioned during the
meeting. The annotated document will be given to the author at the end of the logging
meeting. Using checklists during this phase can make reviews more effective and efficient,
for example a specific checklist based on perspectives such as user, maintainer, tester or
operations, or a checklist for typical coding problems.

Review meeting
The meeting typically consists of the following elements (partly depending on the
review type): logging phase, discussion phase and decision phase.
During the logging phase the issues, e.g. defects, that have been identified during the
preparation are mentioned page by page, reviewer by reviewer and are logged either by the
author or by a scribe. A separate person to do the logging (a scribe) is especially useful for
formal review types such as an inspection. To ensure progress and efficiency, no real discussion
is allowed during the logging phase. If an issue needs discussion, the item is logged and then
handled in the discussion phase. A detailed discussion on whether or not an issue is a defect is
not very meaningful, as it is much more efficient to simply log it and proceed to the next one.
Furthermore, in spite of the opinion of the team, a discussed and discarded defect may well turn
out to be a real one during rework.

Every defect and its severity should be logged. The participant who identifies the
defect proposes the severity. Severity classes could be:
 Critical: defects will cause downstream damage; the scope and impact of the defect is
beyond the document under inspection.
 Major, defects could cause a downstream effect (e.g. a fault in a design can result in an error
in the implementation).
 Minor, defects are not likely to cause downstream damage (e.g. non-compli ance with the
standards and templates).

Rework
Based on the defects detected, the author will improve the document under review
step by step. Not every defect that is found leads to rework. It is the author's responsibility to
judge if a defect has to be fixed. If nothing is done about an issue for a certain reason, it should
be reported to at least indicate that the author has considered the issue.
Changes that are made to the document should be easy to identify during follow-up. Therefore
the author has to indicate where changes are made (e.g. using 'Track changes' in word-
processing software).

Follow-up
The moderator is responsible for ensuring that satisfactory actions have been taken on
all (logged) defects, process improvement suggestions and change requests. Although the
moderator checks to make sure that the author has taken action on all known defects, it is not
necessary for the moderator to check all the corrections in detail. If it is decided that all
participants will check the updated document, the moderator takes care of the distribution and
collects the feedback. For more formal review types the moderator checks for compliance to the
exit criteria.
In order to control and optimize the review process, a number of measurements are
collected by the moderator at each step of the process. Examples of such measurements include
number of defects found, number of defects found per page, time spent checking per page,
total review effort, etc. It is the responsibility of the moderator to ensure that the information is
correct and stored for future analysis.

http://sif.uin-suska.ac.id
http://fst.uin-suska.ac.id
http://www.uin-suska.ac.id
Website Resmi Kampus
Universitas Islam Negeri Sultan Syarif Kasim
Riau

Chapter Three Static Techniques

More Related Content

What's hot (20)

Similar to Chapter Three Static Techniques (20)

Recently uploaded (20)

Chapter Three Static Techniques