The document discusses static techniques for software testing, including static analysis and reviews. It describes static testing as examining software work products like code manually or with tools without executing it. Reviews can range from informal to formal, with formal reviews involving planning, preparation by reviewers finding defects, a review meeting, rework by the author, and follow-up. The roles of moderator, author, scribe and reviewer in formal reviews are also outlined. Types of reviews like walkthroughs, technical reviews and inspections are also described. Finally, the document discusses how static analysis tools can find defects in code, standards, metrics and structure.
2. 1. REVIEWS AND THE TEST PROCESS
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.
3. 2. REVIEW PROCESS
Reviews vary from very informal to formal (i.e. well structured
and regulated). Although inspection is perhaps the most
documented and formal review tech-nique, 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.
4. A. 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
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.
2. 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.
5. Continue...
3 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.
4 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.
6. Continue...
5 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.
6 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.
7. b. Roles and Responsibilities
The participants in any type of formal review should have adequate
knowledge of the review process. The best, and most efficient, review situation
occurs when the participants gain some kind of advantage for their own work
during review-ing.
The best formal reviews come from well-organized teams, guided by trained
moderators (or review leaders). Within a review team, four types of participants
can be distinguished: moderator, author, scribe and reviewer. In addition man-
agement needs to play a role in the review process.
8. c. Types of review
A single document may be the subject of more than one review. If more
than one type of review is used, the order may vary. The main review types,
their main characteristics and common objectives are described below
Walkthrough
A walkthrough is characterized by the author of the document under
review guiding the participants through the document and his or her thought
processes, to achieve a common understanding and to gather feedback.
Technical review
A technical review is a discussion meeting that focuses on achieving
consensus about the technical content of a document.
9. Continue...
Inspection
Inspection is the most formal review type. The document under
inspection is prepared and checked thoroughly by the reviewers before the
meeting, comparing the work product with its sources and other referenced
documents, and using rules and checklists. In the inspection meeting the
defects found are logged and any discussion is postponed until the
discussion phase. This makes the inspection meeting a very efficient meeting.
10. d. Success factors for reviews
The next list contains a number of critical success factors that improve the chances of
success when implementing reviews. It aims to answer the question, 'How do you start
(formal) reviews?'.
Find a 'champion'
Pick things that really count
Explicitly plan and track review activities
Train participants
Manage people issues
Follow the rules but keep it simple
Continuously improve process and tools
Report results
Just do it!
11. 3.STATIC ANALYSIS BY TOOLS
Static analysis is an examination of requirements, design and code that
differs from more traditional dynamic testing in a number of important
ways:
Static analysis is performed on requirements, design or code without
actually executing the software artifact being examined.
Static analysis is ideally performed before the types of formal review
discussed in Section 3.2.
Static analysis is unrelated to dynamic properties of the requirements,
design and code, such as test coverage.
The goal of static analysis is to find defects, whether or not they may
cause failures. As with reviews, static analysis finds defects rather than
failures.
12. Continue...
The various features of static analysis tools are discussed below, with a special focus
toward static code analysis tools since these are the most common in day-to-day practice.
Note that static analysis tools analyze software code, as well as generated output such as
HTML and XML.
Coding standards
Code metrics
Code structure
13. Reference
Graham,d., et al.2006. Foundation of Software Testing : ISTQB
certification London, UK : International Thomson Business Press
