The document discusses static techniques for testing software work products like code, requirements, and design specifications. Static techniques like reviews and static analysis aim to find defects early before testing to improve productivity and reduce costs. Reviews involve examining documentation for defects, while static analysis checks code complexity, errors, and other issues without executing the code. Formal reviews follow steps like planning, kickoff meetings, preparation, review meetings, reworking defects, and follow up. Roles include managers, moderators, authors, reviewers, and scribes.

1. Static Technique
NOPRI WAHYUDI
11453105420
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/
Referensi Graham et.al (2006)

2. Static Technique
-Review-
 A way of testing software work products
 Program code, requirment spec., design spec
 Test plan, test design, test cases, test script, user guides.
 Early defect detection and correction of software development.
 Development productivity improvements, reduce development
time, reduce testing cost and time.
 Fewer defects and improved communication.
 Reviews, static analysis and dynamic testing have the same
objective identifiying defects
 Reviews : find the causes of failures (defect) rather the defect
themselve
 Static analysis : complexity of code, error in statement, missing
parameter, dead code, etc.

3. Why Review
 More efficient detecting defects in review that dynamic test
 Component test perio; 2-4 findings per hour
 Code review; 6-10 findings per hour
 Cost of fixing defects after component test level
 10-14 m/h for finding and fixing defects during integration or
system test level
 1 m/h for finding and fixing defect during inspection
 Time and cost efficiency when quick defect correction

4. Reasons of Review
 Effective deffects detecting
 Gaining understanding of documentation
 Determining and deciding through the discussion
 When auditing is planned
 Statisfying requirement or compliance
 Needed to be high quality in developing process

5. Roles and Responsibility
 Manager
 Decide on the execution of reviews, allocates time in project schedules and
determine if the review objectives had been met.
 Moderator
 Leads the review of the documents, planning the review and running the
meeting and follow-up after meeting
 Author
 The writer or person with chief responsibilty of the document(s) to be reviewed
 Reviewers
 Checkers or inspectors
 Reviewers should be chosen to represent different perspectives and roles in
the review process
 Scribe (recorder)
 Documents all the issues, problems and open points

6. Review Process
Step Role Goal
Planning Manager Assign role, define entry/exit criteria,
identify documentation to be reviewed
Kick-off Moderator
Reviewer
Author
Distribute documentation
Explain the goal of documentation and
process
Check entry criteria for the review
Preparatio
n
Reviewer Preapre about review meeting, try to find
possible deffects and comments
Review Moderator
Reviewer
Author/Scrib
e
Recording defects during the review
meeting
Do not try to solve the problem
Rework Author Fix the defect found (typically by author)
Follow Up Moderator Check all the defect found fixed, collect
metrics and confirm
Check the exit criteria for the review.

7. 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.

8. 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.During the kick-off
meeting the reviewers receive a short introduction on the objectives of
the review and the documents. The relationships between the
document under review and the other documents (sources) are
explained, especially if the number of related documents is high.
Role assignments, checking rate, the pages to be checked, process
changes and possible other questions are also discussed during this
meeting. Of course the distribution of the document under review,
source documents and other related documentation, can also be done
during the kick-off.

9. 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). ,
 In order to keep the added value of reviews, spelling errors are
not part of the defect classification. Spelling defects are noted,
by the participants, in the document under review and given to
the author at the end of the meeting or could be dealt with in a
separate proofreading exercise.

10. 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
reviewing. In the case of an inspection or technical review,
participants should have been properly trained as both types
of review have proven to be far less successful without
trained participants. This indeed is perceived as being a
critical success factor.
 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
management needs to play a role in the review process.

11. 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.