Static techniques such as reviews can improve both quality and productivity in software development. Static testing examines software work products like requirements and design documents manually or with tools before execution, finding defects early. Dynamic testing executes software with test cases. The two techniques are complementary, as static testing finds defects like missing requirements or design flaws while dynamic testing finds failures from execution. Using static testing from early in the development lifecycle provides advantages like early feedback, low rework costs, increased productivity, and greater awareness of quality issues.

1. Static techniques
Nama : MINI MARSIAH
Nim : 11453201774
Jurusan : SISTEM INFORMASI
Fakultas : SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU

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

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

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

5. In contrast to informal reviews, formal reviews follow a formal process. A typical
formal review process consists of six main steps:
 Planning
 Kick-off
 Preparation
 Review meeting
 Rework
 Follow-up.
Phases of a formal review

6.  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.
 Although more and other entry criteria can be applied, the following can be regarded as the
minimum set for performing the entry check:
1. A short check of a product sample by the moderator (or expert) does not reveal a large number of
major defects. For example, after 30 minutes of checking, no more than 3 major defects are found
on a single page or fewer than 10 major defects in total in a set of 5 pages.
2. The document to be reviewed is available with line numbers.
3. The document has been cleaned up by running any automated checks that apply.
4. References needed for the inspection are stable and available.
5. The document author is prepared to join the review team and feels confident with the quality of
the document.
Planning

7.  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]
Kick-off

8.  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.
Preparation

9.  The meeting typically consists of the following elements (partly depending on
the review type): logging phase, discussion phase and decision phase.
 Every defect and its severity should be logged. The participant who identifies
the defect proposes the severity. Severity classes could be:
1. Critical: defects will cause downstream damage; the scope and impact of the
defect is beyond the document under inspection
2. Major, defects could cause a downstream effect (e.g. a fault in a design can
result in an error in the implementation).
3. Minor, defects are not likely to cause downstream damage (e.g. non-compli
ance with the standards and templates). ,
Review meeting

10.  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).
Rework

11.  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.
Follow-up