Static techniques

HELLO! I AM 
STUDENT AND BUSINESSMAN
Student of Information System (http://sif.uin-
suska.ac.id/)
Faculty of Sains And Technology (http://fst.uin-
suska.ac.id/)
State Islamic University of Sultan Syarif Kasim
Riau (https://uin-suska.ac.id/)

Static techniques
TESTING IMPLEMENTATION SYSTEM

Introduction SLIDE 3
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.

1. REVIEWS AND THE TEST
PROCESS SLIDE 4
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.

1. REVIEWS AND THE TEST
PROCESS SLIDE 5
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 prod ucts 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.

2. REVIEW PROCESS SLIDE 6
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
2 Kick-off
3 Preparation
4 Review meeting
5 Rework
6 Follow-up.

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. 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.
2. REVIEW PROCESS

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. 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 eenendaal and Van der Zwan,
2000]
2. REVIEW PROCESS

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. 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.
2. REVIEW PROCESS

4. Review Meeting
The meeting typically consists of the following elements (partly depending on the review
type): logging phase, discussion phase and decision phase.
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-compliance with the standards
and templates).
2. REVIEW PROCESS

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. 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).
2. REVIEW PROCESS

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.
2. REVIEW PROCESS

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

1. The Moderator
The moderator (or review leader) leads the review process. He or she
determines, in co-operation with the author, the Type of review, approach and the
Composition Of the review team. The moderator performs the entry check and the
follow-up on the rework, in order to control the quality of the input and output of the
review process. The moderator also schedules the meeting, disseminates documents
before the meeting, coaches other team members, paces the meeting, leads possible
discussions and stores the data that is collected.
2. REVIEW PROCESS

2. The Author
As the writer of the document under review, the author's basic goal should be to
learn as much as possible with regard to improving the quality of the document, but also
to improve his or her ability to write future documents. The author's task is to illuminate
unclear areas and to understand the defects found.
2. REVIEW PROCESS

3. The Scribe
During the logging meeting, the scribe (or recorder) has to record each defect
mentioned and any suggestions for process improvement. In practice it is often the
author who plays this role, ensuring that the log is readable and understandable. If
authors record their own defects, or at least make their own notes in their own words, it
helps them to understand the log better during rework. However, having someone other
than the author take the role of the scribe (e.g. the moderator) can have significant
advantages, since the author is freed up to think about the document rather than being
tied down with lots of writing.
2. REVIEW PROCESS

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.
For example, an informal review may be carried out before a
technical review, or an inspection may be carried out on a
requirements specification before a walkthrough with customers. It is
apparent that none of the following types of review is the 'winner',
but the different Types Serve Different Purposes at different stagesIn
The Life Cycle Of A document

1. Technical Review
The goals of a technical review are to:
• assess the value of technical concepts and alternatives in the product and project environment;
• establish consistency in the use and representation of technical concepts;
• ensure, at an early stage, that technical concepts are used correctly;
• inform participants of the technical content of the document.
Key characteristics of a technical review are:
• It is a documented defect-detection process that involves peers and technical experts.
• It is often performed as a peer review without management participation.
• Ideally it is led by a trained moderator, but possibly also by a technical expert.
• A separate preparation is carried out during which the product is examined and the defects are found.
• More formal characteristics such as the use of checklists and a logging list or issue log are optional.
2. REVIEW PROCESS

1. Technical Review
The generally accepted goals of inspection are to:
• help the author to improve the quality of the document under inspection;
• remove defects efficiently, as early as possible;
• improve product quality, by producing documents with a higher level of quality;
• create a common understanding by exchanging information among the inspection participants;
• train new employees in the organization's development process;
• learn from defects found and improve processes in order to prevent recurrence of similar defects;
• sample a few pages or sections from a larger document in order to measure the typical quality of the document,
leading to improved work by individuals in the future, and to process improvements.
2. REVIEW PROCESS

1. Technical Review
Key characteristics of an inspection are:
• It is usually led by a trained moderator (certainly not by the author).
• It uses defined roles during the process.
• It involves peers to examine the product.
• Rules and checklists are used during the preparation phase.
• A separate preparation is carried out during which the product is examined and the defects are found.
• The defects found are documented in a logging list or issue log.
• A formal follow-up is carried out by the moderator applying exit criteria.
• Optionally, a causal analysis step is introduced to address process improvement issues and learn from the defects
found.
• Metrics are gathered and analyzed to optimize the process.
2. REVIEW PROCESS

D. Success factor for review
1. Find a 'champion’
2. Pick things that really count
3. Explicitly plan and track review activities
4. Train participants
5. Manage people issues
6. Follow the rules but keep it simple
7. Continuously improve process and tools
8. Report results
9. Just do it!

Thank you very much! 
Reference: Graham et al Foundationf of Software Testing

Static techniques

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Similar to Static techniques

Similar to Static techniques (18)

Recently uploaded

Recently uploaded (20)

Static techniques