3.

1 Static Testing Basics Static

Testing
Static Analysis
Static analysis is important for safety-critical Static
computer systems, but static analysis has also Reviews
become important and common in other
Analysis
settings.
•static analysis is an important part of security testing
•Static analysis can be applied efficiently to any work product with a formal
structure (typically code or models) for which an appropriate static analysis
tool exists
•Static analysis can even be applied with tools that evaluate work products
written in natural language such as requirements (e.g., checking for spelling,
grammar, and readability).

Benefits of Static Testing

Defects that are easier to find and fix in
Static Testing:
1. Requirements defects.
2. Design defects.
3. Coding defects.
4. Deviations from standards.
5. Incorrect interface specifications.
6. Security vulnerabilities.
7. Gaps or inaccuracies in test basis
traceability or coverage.
8. Maintainability Defects.
 Review Process:
--->formal
--->In formal
-Planning

-Initial review

-Individual review

-Issue communication and analysis

-Fixing and reporting (author)

1-Planning 2-Initiate review

 Defining the scope

 Distributing the work product.
 Estimating effort and timeframe

‫ثببث‬
 Explaining the scope, objectives, process,
Identifying review characteristics such as the review roles, and work products to the participants.
type with roles, activities, and checklists
 Answering any questions that participants
 Selecting the people to participate in the review and may have about the review.
allocating roles

 Defining the entry and exit criteria for more formal Issue communication and analysis
review types (e.g., inspections)
 Communicating identified potential
 Checking that entry criteria are met. defects (e.g., in a review meeting)
 Analyzing potential defects, assigning
ownership and status to them
Fixing and reporting  Evaluating and documenting quality
characteristics
 Creating defect reports  Evaluating the review findings against the
 Fixing defects found exit criteria to make a review decision
 Communicating defects to the appropriate person or
team
 Recording updated status of
 Gathering metrics Individual review (i.e., individual preparation)
 Checking that exit criteria are met
 Accepting the work product when the exit criteria are  Reviewing all or part of the work product
reached
 Noting potential defects, recommendations, and
questions
 Review Roles:

Management-

Reviewers-

Author-
Roles and responsibilities in a formal review:
Facilitator (moderator- )

Review Leader-
1- Author
 Creates the work product under review
2- Management
 Fixes defects in the work product under
review (if necessary)
 Is responsible for review planning

3-Facilitator (often called moderator)

 Decides on the execution of reviews
 Ensures effective running of review meetings
(when held)
 Assigns staff, budget, and time
 Mediates, if necessary, between the various
points of view
 Monitors ongoing cost-effectiveness

 Is often the person upon whom the success of

the review depends  Executes control decisions in the event of
inadequate outcomes

4- Review leader

 Takes overall responsibility for the review.

 Decides who will be involved and organizes when and where it will take place.

5-Reviewers

 May be subject matter experts, persons working on the project, stakeholders

with an interest in the work product, and/or individuals with specific technical or
business backgrounds

 Identify potential defects in the work product under review

 May represent different perspectives

 Review Types:
-Informal Review (buddy)
-Walkthrough (Author)
Review Types
-Technical Review
-Inspection

Informal review (e.g., buddy check, pairing, pair review)

Main purpose: detecting potential defects

 Possible additional purposes: generating new ideas or solutions, quickly solving minor problems

 Not based on a formal (documented) process

 May not involve a review meeting

 May be performed by a colleague of the author (buddy check) or by more people

 Results may be documented

 Varies in usefulness depending on the reviewers

 Use of checklists is optional

 Very commonly used in Agile development

Walkthrough

 Main purposes: find defects, improve the software product, consider alternative implementations, evaluate conformance
to standards and specifications

 Possible additional purposes: exchanging ideas about techniques or style variations, training of participants, achieving
consensus

 Individual preparation before the review meeting is optional

 Review meeting is typically led by the author of the work product

 Scribe is mandatory.

 Use of checklists is optional.

 May take the form of scenarios, dry runs, or simulations.

 Potential defect logs and review reports are produced.

 May vary in practice from quite informal to very formal.

 Technical review

 Main purposes: gaining consensus, detecting potential defects

 Possible further purposes: evaluating quality and building confidence in the work product, generating new ideas,
‫رييسيسسيسي‬
motivating and enabling authors to improve future work products, considering alternative implementations

 Reviewers should be technical peers of the author, and technical experts in the same or other disciplines

 Individual preparation before the review meeting is required

 Review meeting is optional, ideally led by a trained facilitator (typically not the author)

 Scribe is mandatory, ideally not the author

 Use of checklists is optional

 Potential defect logs and review reports are produced

Inspection
 Main purposes: detecting potential defects, evaluating quality and building confidence in the work product,
preventing future similar defects through author learning and root cause analysis.

 Possible further purposes: motivating and enabling authors to improve future work products and the software
development process, achieving consensus.

 Follows a defined process with formal documented outputs, based on rules and checklists.

 Uses clearly defined roles, such as those specified in section 3.2.2 which are mandatory, and may include a dedicated
reader (who reads the work product aloud often paraphrase, i.e. describes it in own words, during the review meeting).

 Individual preparation before the review meeting is required.

 Reviewers are either peers of the author or experts in other disciplines that are relevant to the work product.

-Specified entry and exit criteria are used.

 Scribe is mandatory.

 Review meeting is led by a trained facilitator (not the author).

 Author cannot act as the review leader, reader, or scribe.

 Potential defect logs and review report are produced.

 Metrics are collected and used to improve the entire software development process, including the inspection process.

Peer Review

The types of review described above can be done as peer reviews

(i.e. done by colleagues at a similar approximate organizational level).
 Review Techniques:
Applying Review Techniques
-Checklist based
There are a number of review techniques that can be
-Ad hoc (no planning)
applied during the individual review (i.e., individual
preparation) activity to uncover defects. -Scenario & dry run

These techniques can be used across the review types -Role-based

described above. -Perspective based

1-Ad hoc
In an ad hoc review, reviewers are provided with little or no guidance on how this task should be performed. Reviewers often read
the work product sequentially, identifying and documenting issues as they encounter them.

Ad hoc reviewing is a commonly used technique needing little preparation.

This technique is highly dependent on reviewer skills and may lead to many duplicate issues being reported by different reviewers.

2-Checklist-based
1-A checklist-based review is a systematic technique, whereby the reviewers detect issues based on checklists
that are distributed at review initiation (e.g., by the facilitator).
2- A review checklist consists of a set of questions based on potential defects, which may be derived from
experience.
3-Checklists should be specific to the type of work product under review and should be maintained regularly to
cover issue types missed in previous reviews.
4-The main advantage of the checklist-based technique is a systematic coverage of typical defect types. Care
should be taken not to simply follow the checklist in individual reviewing, but also to look for defects outside
the checklist.

3-Scenarios and dry runs

In a scenario-based review, reviewers are provided with structured guidelines on how to read through the work
product.
A scenario-based review supports reviewers in performing “dry runs” on the work product based on expected
usage of the work product (if the work product is documented in a suitable format such as use cases).
These scenarios provide reviewers with better guidelines on how to identify specific defect types than simple
checklist entries.
As with checklist-based reviews, in order not to miss other defect types (e.g., missing features), reviewers
should not be constrained to the documented scenarios.
 4-perspective-based
In perspective-based reading, similar to a role-based review, reviewers take on different stakeholder
viewpoints in individual reviewing.
Typical stakeholder viewpoints include end user, marketing, designer, tester, or operations.
Using different stakeholder viewpoints leads to more depth in individual reviewing with less duplication of
issues across reviewers.
‫يب‬
Empirical studies have shown perspective-based reading to be the most effective general technique for
reviewing requirements and technical work products.

5-Role-based
A role-based review is a technique in which the reviewers evaluate the work product from the
perspective of individual stakeholder roles.
Typical roles include specific end user types (experienced, inexperienced, senior, child, etc.),
and specific roles in the organization (user administrator, system administrator, performance
tester, etc.).
The same principles apply as in perspective-based reading because the roles are similar.

Success Factors for Reviews

Organizational success factors for reviews include:

 Each review has clear objectives, defined during review planning, and used as measurable exit criteria

 Review types are applied which are suitable to achieve the objectives and are appropriate to the type and level
of software work products and participants

 Any review techniques used, such as checklist-based or role-based reviewing, are suitable for effective defect
identification in the work product to be reviewed.

 Any checklists used address the main risks and are up to date.

 Large documents are written and reviewed in small chunks, so that quality control is exercised by providing
authors early and frequent feedback on defects.

 Participants have adequate time to prepare

 Reviews are scheduled with adequate notice

 Management supports the review process

 Reviews are integrated in the company's quality and/or test policies.

People-related success factors for reviews include:

 The right people are involved to meet the review objectives.

 Testers are seen as valued reviewers.

 Participants dedicate adequate time and attention to detail.

 Reviews are conducted on small chunks, so that reviewers do not lose concentration during individual review
and/or the review meeting.

 Defects found are acknowledged, appreciated, and handled objectively.

 The meeting is well-managed, so that participants consider it a valuable use of their time

 The review is conducted in an atmosphere of trust; the outcome will not be used for the evaluation of the
participants.

 Participants avoid body language and behaviors that might indicate boredom, exasperation, or hostility to
other participants

 Adequate training is provided, especially for more formal review types.

 A culture of learning and process improvement is promoted.