Static Techniques (K2) 3.1. Static Techniques and The Test Process (K2)

09/11/2017
Fundamentals Life Cycle Fundamentals Life Cycle

3.1. Static Techniques and the
Static Design
3. Static Techniques (K2) Static Design
Management Tool Support Management Tool Support Test Process (K2)

1. Static Techniques and the Test Process (K2) Terms
Dynamic testing, static testing
2. Review Process (K2)
Testing
3. Static Analysis by Tools (K2) Learning Objectives (LO):
LO-3.1.1 Recognize software work products that can be examined by the
K1 (Remember) different static techniques (K1)
K2 (Understand) Static Dynamic
LO-3.1.2 Describe the importance and value of considering static techniques for
K3 (Apply) the assessment of software work products (K2)
K4 (Analyze)
K5 (Evaluate) Static LO-3.1.3 Explain the difference between static and dynamic techniques,
K6 (Create) Review
Analysis considering objectives, types of defects to be identified, and the role of these
techniques within the software life cycle (K2)
MAB@dsi.uminho.pt 2016 97 MAB@dsi.uminho.pt 2016 98
Fundamentals
Static
Life Cycle
Design
3.1. Static Techniques and the Fundamentals
Static
Life Cycle
Design
Management Tool Support Test Process (K2) Management Tool Support Test Process (K2)
Testing Reviews can be performed well before dynamic test
requires the
execution.
without the execution of the code execution of software Defects detected during reviews early in the life cycle (e.g.,
Static Dynamic defects found in requirements) are often much cheaper to
remove than those detected by running tests on the
manual
examination Static Automated analysis executing code.
Review
Analysis A review could be done entirely as a manual activity, but
there is also tool support.
The main manual activity is to examine a work product and
make comments about it
09/11/2017
Fundamentals
Static
Life Cycle
Design
Static
Life Cycle
Design
Benefits of reviews include:
Any software work product can be reviewed, including:
• early defect detection and • reduced testing cost and
• requirements specifications, • test cases, correction, time,
• design specifications, • test scripts, • development productivity • lifetime cost reductions,
improvements, • fewer defects,
• code, • user guides,
• reduced development • improved communication.
• test plans, • web pages. timescales,
• test specifications,
Reviews can find omissions, for example, in requirements,
which are unlikely to be found in dynamic testing
Fundamentals
Static
Life Cycle
Design
Static
Life Cycle
Design
Testing
Typical defects that are easier to find in reviews than
find causes of in dynamic testing include:
failures (defects) find failures
Static Dynamic • deviations from standards,
• requirement defects,
Review
Static
Analysis • design defects,
All have the same objective – identifying defects. • insufficient maintainability and
They are complementary; the different techniques can find different types of defects • incorrect interface specifications
effectively and efficiently.
09/11/2017
Static Design
3.2 Review Process (K2) Static Design
3.2 Review Process (K2)
Management Tool Support Management Tool Support
The formality of a review process is related to factors

Terms Formal
such as:
Entry criteria, formal review, informal review, inspection, metric, moderator, • maturity of the development process (systematic)
peer review, reviewer, scribe, technical review, walkthrough • team participation
• legal or regulatory requirements
• need for an audit trail. • documented results of
Learning Objectives (LO): the review
LO-3.2.1 Recall the activities, roles and responsibilities of a typical formal review • documented procedures for
(K1) conducting the review.
LO-3.2.2 Explain the differences between different types of reviews: informal
review, technical review, walkthrough and inspection (K2)
LO-3.2.3 Explain the factors for successful performance of reviews (K2) Informal
• no written instructions for reviewers
Static Design
3.2.1 Activities of a Formal Review (K1) 3.2.1 Activities of a Formal Review (K1)
The way a review is carried out A typical formal review has the 1. Planning
following main activities (see next slides):
depends on the agreed objectives. • Defining the review criteria
e.g., 1. Planning
• Selecting the personnel
• find defects, 2. Kick-off
• gain understanding, 3. Individual preparation
• Allocating roles
• educate testers and new team 4. Review Meeting (Examination / • Defining the entry and exit criteria for more formal review types
members, evaluation / recording of results) (e.g., inspections)
• discussion and decision by 5. Rework • Selecting which parts of documents to review
consensus. 6. Follow-up • Checking entry criteria (for more formal review types)
09/11/2017
Static Design
3.2.1 Activities of a Formal Review (K1) 3.2.1 Activities of a Formal Review (K1)
2. Kick-off
4. Review Meeting (Examination / evaluation / recording of results)
• Distributing documents
• Discussing or logging, with documented results or minutes (for more
• Explaining the objectives, process and documents to the participants formal review types)
• Noting defects, making recommendations regarding handling the
3. Individual preparation defects, making decisions about the defects
• Preparing for the review meeting by reviewing the document(s) • Examining / evaluating and recording issues during any physical
meetings or tracking any group electronic communications
• Noting potential defects, questions and comments
Static Design
3.2.1 Activities of a Formal Review (K1) 3.2.2 Roles and Responsibilities (K1)
A typical formal review will include these roles (see next slides):
5. Rework • Manager
• Fixing defects found (typically done by the author) • Moderator
• Author
• Recording updated status of defects (in formal reviews) • Reviewers
6. Follow-up • Scribe (or recorder)
• Checking that defects have been addressed Looking from different perspectives and using checklists can make reviews more
effective and efficient. For example,
• Gathering metrics • checklist based on various perspectives such as user, maintainer, tester or
operations,
• Checking on exit criteria (for more formal review types) • checklist of typical requirements problems may help to uncover previously
undetected issues.
09/11/2017
Static Design
3.2.2 Roles and Responsibilities (K1) 3.2.2 Roles and Responsibilities (K1)
• Manager:
• decides on the execution of reviews
• allocates time in project schedules • Reviewers: individuals with a specific technical or business
• determines if the review objectives have been met. background (also called checkers or inspectors).
• Moderator: leads the review of the documents, including • After the necessary preparation, identify and describe findings (e.g., defects)
• planning the review in the product under review.
• running the meeting • Reviewers should be chosen to represent different perspectives and roles in
• following-up after the meeting. the review process, and should take part in any review meetings.
• If necessary, the moderator may mediate between the various points of view and is • Scribe (or recorder): documents all the issues, problems and open
often the person upon whom the success of the review rests.
points that were identified during the meeting.
• Author: the writer or person with chief responsibility for the document(s)
to be reviewed.
Static Design
3.2.3 Types of Reviews (K2) 3.2.3 Types of Reviews (K2)
Common review types are (see next slides)

• Informal Review Informal Review
• Walkthrough • No formal process
• Technical Review • May take the form of pair programming or a technical lead reviewing
• Inspection designs and code
Walkthroughs, technical reviews and inspections can be performed within a
peer group. This type of review is called a “peer review”. • Results may be documented
If more than one type of review is used for the same work product, the order • Varies in usefulness depending on the reviewers
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 • Main purpose: inexpensive way to get some benefit
specification before a walkthrough with customers.
09/11/2017
Static Design
3.2.3 Types of Reviews (K2) 3.2.3 Types of Reviews (K2)

Technical Review • Preparation of a review report which
Walkthrough • Documented, defined defect-detection includes the list of findings, the verdict
process that includes peers and whether the software product meets its
• Meeting led by author requirements and, where appropriate,
technical experts with optional
• May take the form of scenarios, dry runs, peer group participation management participation recommendations related to findings
• Open-ended sessions • May be performed as a peer review • May vary in practice from quite
without management participation informal to very formal
• Optional pre-meeting preparation of reviewers
• Optional preparation of a review report including list of findings • Ideally led by trained moderator (not • Main purposes: discussing, making
the author) decisions, evaluating alternatives,
• Optional scribe (who is not the author) finding defects, solving technical
• Pre-meeting preparation by reviewers problems and checking conformance
• May vary in practice from quite informal to very formal to specifications, plans, regulations,
• Optional use of checklists
• Main purposes: learning, gaining understanding, finding defects and standards
Static Design
3.2.3 Types of Reviews (K2) 3.2.4 Success Factors for Reviews (K2)
Inspection for acceptance of the software • Each review has clear predefined objectives
• Led by trained moderator (not the product • The right people for the review objectives are • Review techniques are applied that are suitable
author) • Pre-meeting preparation involved to achieve the objectives and to the type and
level of software work products and reviewers
• Testers are valued reviewers who contribute to
• Usually conducted as a peer • Inspection report including list of the review and also learn about the product • Checklists or roles are used if appropriate to
examination findings which enables them to prepare tests earlier increase effectiveness of defect identification
• Defects found are welcomed and expressed • Training is given in review techniques, especially
• Defined roles • Formal follow-up process (with objectively the more formal techniques such as inspection
• Includes metrics gathering optional process improvement • People issues and psychological aspects are • Management supports a good review process
components) dealt with (e.g., making it a positive experience (e.g., by incorporating adequate time for review
• Formal process based on rules for the author) activities in project schedules)
and checklists • Optional reader • The review is conducted in an atmosphere of • There is an emphasis on learning and process
• Main purpose: finding defects trust; the outcome will not be used for the improvement
• Specified entry and exit criteria evaluation of the participants
09/11/2017
Static Design
3.3 Static Analysis by Tools (K2) Static Design
3.3 Static Analysis by Tools (K2)
Terms
Compiler, complexity, control flow, data flow, static analysis
The objective of static analysis is to find defects in software
source code and software models. Static analysis is
performed without actually executing the software being
Learning Objectives (LO): examined by the tool; dynamic testing does execute the
LO-3.3.1 Recall typical defects and errors identified by static analysis software code. Static analysis can locate defects that are
and compare them to reviews and dynamic testing (K1)
LO-3.3.2 Describe, using examples, the typical benefits of static analysis
hard to find in dynamic testing. As with reviews, static
(K2) analysis finds defects rather than failures. Static analysis
LO-3.3.3 List typical code and design defects that may be identified by tools analyze program code (e.g., control flow and data
static analysis tools (K1) flow), as well as generated output such as HTML and XML
Static Design
3.3 Static Analysis by Tools (K2)
The value of static analysis is: Typical defects discovered by • Missing and erroneous logic
• Early detection of defects prior to test execution static analysis tools include: (potentially infinite loops)
• Early warning about suspicious aspects of the code or design • Referencing a variable with • Overly complicated
by the calculation of metrics, such as a high complexity an undefined value constructs
measure • Inconsistent interfaces • Programming standards
• Identification of defects not easily found by dynamic testing between modules and violations
• Detecting dependencies and inconsistencies in software components • Security vulnerabilities
models such as links • Variables that are not used • Syntax violations of code and
• Improved maintainability of code and design or are improperly declared software models
• Prevention of defects, if lessons are learned in development • Unreachable (dead) code
09/11/2017
Static Design
Classwork -- chapter 3 practice
Static analysis tools are typically used by developers (checking • Solve the exercises in the following slides
against predefined rules or programming standards) before and • [In https://www.proprofs.com/quiz-school/story.php?title=istqb-chapter-3]
during component and integration testing or when checking-in • Homework:
code to configuration management tools, and by designers
during software modeling. • Search the internet for additional online exams and assess
yourself (search for “ istqb mock test”)
Static analysis tools may produce a large number of warning • Note: Be aware that not all the online quizzes are well fitted with
messages, which need to be well-managed to allow the most
effective use of the tool. the ISTQB chapters. It may happen that a question of a later
chapter appears in a chapter three exercise… no stress.
Compilers may offer some support for static analysis, including
the calculation of metrics.
Static
Management
Design
Tool Support
Classwork -- chapter 3 practice Static
Management
Design
Tool Support
1. Which of the following artifacts can be examined 2. Which statement about the function of a static analysis tool is
true?
by using review techniques?
A. Gives quality information about the code without executing it.
A. Software code B. Checks expected results against actual results.
B. Requirements specification C. Can detect memory leaks.
D. Gives information about what code has and has not been exercised.
C. Test designs
D. All of the above
09/11/2017
Static
Management
Design
Tool Support
Management
Design
Tool Support
3. Which is not a type of review? 4. What statement about reviews is true?
A. Inspections are led by a trained moderator, whereas technical

A. Walkthrough reviews are not necessarily.
B. Inspection B. Technical reviews are led by a trained leader, inspections are not.
C. Informal review C. In a walkthrough, the author does not attend.
D. Participants for a walkthrough always need to be thoroughly
D. Management approval trained.
Static
Management
Design
Tool Support
Management
Design
Tool Support
5. What is the main difference between a walkthrough and an inspection? 6. Which of the following characteristics and types of review processes belong together?
1. Led by the author 2. Undocumented 3. No management participation 4. Led by a trained

A. An inspection is led by the authors, whilst a walkthrough is led by a trained moderator or leader 5. Uses entry and exit criteria
moderator.
B. An inspection has a trained leader, whilst a walkthrough has no leader. s. Inspection t. Technical review u. Informal review v. Walkthrough
C. Authors are not present during inspections, whilst they are during walkthroughs.
D. A walkthrough is led by the author, whilst an inspection is led by a trained
A. S = 4, t = 3, u = 2 and 5, v = 1
moderator B. S = 4 and 5, t = 3, u = 2, v = 1
C. S = 1 and 5, t = 3, u = 2, v = 4
D. S = 5, t = 4, u = 3, v = 1 and 2

09/11/2017
Static
Management
Design
Tool Support
Management
Design
Tool Support
7. What statement about static analysis is true? 8. Which of the following statements about early test design are true and which
are false?
1. Defects found during early test design are more expensive to fix.
A. With static analysis, defects can be found that are difficult to find
2. Early test design can find defects.
with dynamic testing. 3. Early test design can cause changes to the requirements.
B. Compiling is not a form of static analysis. 4. Early test design takes more effort.
C. When properly performed, static analysis makes functional testing
redundant. A. 1 and 3 are true. 2 and 4 are false.
D. Static analysis finds all faults. B. 2 is true. 1, 3 and 4 are false.
C. 2 and 3 are true. 1 and 4 are false.
D. 2, 3 and 4 are true. 1 is false.
Fundamentals Life Cycle
Static
Management
Design
Tool Support
9. Static code analysis typically identifies all but one of the

following problems. Which is it?
A. Unreachable code
B. Undeclared variables
C. Faults in the requirements
D. Too few comments
MAB@dsi.uminho.pt 2016 135

Static Techniques (K2) 3.1. Static Techniques and The Test Process (K2)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Static Techniques (K2) 3.1. Static Techniques and The Test Process (K2)

Uploaded by

Copyright:

Available Formats

09/11/2017

Fundamentals Life Cycle Fundamentals Life Cycle

Management Tool Support Management Tool Support Test Process (K2)

Fundamentals Life Cycle Fundamentals Life Cycle

The formality of a review process is related to factors

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

3.2.3 Types of Reviews (K2) 3.2.3 Types of Reviews (K2)

Common review types are (see next slides)

Fundamentals Life Cycle Fundamentals Life Cycle

3.2.3 Types of Reviews (K2) 3.2.3 Types of Reviews (K2)

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle Fundamentals Life Cycle

3. Which is not a type of review? 4. What statement about reviews is true?

A. Inspections are led by a trained moderator, whereas technical

MAB@dsi.uminho.pt 2016 129 MAB@dsi.uminho.pt 2016 130

Fundamentals Life Cycle Fundamentals Life Cycle

1. Led by the author 2. Undocumented 3. No management participation 4. Led by a trained

MAB@dsi.uminho.pt 2016 131 MAB@dsi.uminho.pt 2016 132

Fundamentals Life Cycle Fundamentals Life Cycle

Fundamentals Life Cycle

9. Static code analysis typically identifies all but one of the

MAB@dsi.uminho.pt 2016 135

You might also like