ISTQB Certified Tester

Foundation Level
• Module 3 of 6: Static Techniques

February 2017
Study Sessions

• There are 6 main modules

1. Fundamentals of Testing
2. Testing Throughout the Software Life Cycle
3. Static Techniques
4. Test Design Techniques
5. Test Management
6. Tool Support for Testing

2
Static Techniques
Session Plan

• Static Techniques and the Test Process

• Review Process
• Static Analysis by Tools

4
Static Techniques and the Test Process
Dynamic vs. Static

Dynamic testing requires the execution

of software.
• The software is running

Static testing techniques rely on:

• the manual examination (reviews)
• automated analysis (static analysis) of
the code or other documentation.
• without execution of the code

6
Reviews

• Reviews are a way of testing the software work products (including code) well
before dynamic test execution

• Reviews can be done entirely manually, but there is also tool support.
• The main manual activity is to examine a work product and make comments
• Any software work product can be reviewed including requirements
specifications, design specifications, code, test plans, tests, user guides.

7
Benefits of Static Testing

• Defects detected early in the life cycle (eg. Requirements) are often much cheaper
to fix
• Early defect detection and correction
• Development productivity improvements
• Reduced development timescales
• Reduced testing cost and time
• How many cycles of testing are needed?
• Lifetime cost reductions
• Easier to maintain
• Fewer defects
• Improved communication
8
Objectives

• Reviews, static analysis and dynamic testing have the same objective – identifying
defects. They are complementary; the different techniques can find different
types of defects effectively and efficiently.
• Compared to dynamic testing, static techniques find causes of failures (defects)
rather than the failures themselves.
• Typical defects that are easier to find in reviews than in dynamic testing include:
• deviations from standards
• requirement defects
• design defects / insufficient maintainability
• incorrect interface specifications

9
Review Process
Types of Reviews

• Vary in formality depending on maturity, legal or regulatory requirements or the

need for an audit trail

• Informal
• No written instructions

• Systematic
• Team participation
• Documented results
• Documented procedures

11
Objectives of Reviews

1. Find defects
2. Gain understanding
3. Educate testers and new team
members
4. Discussion and decision by
consensus

12
Activities of a Formal Review

1. Planning:
• Defining the review criteria
• Selecting the personnel
• Allocating roles
2. Defining the entry and exit criteria for more formal review types
(e.g., inspections)
• Selecting which parts of documents to review
3. Kick-off:
• Distributing documents
• Explaining the objectives, process and documents to the participants

13
Activities of a Formal Review continued…

4. Checking entry criteria (for more formal review types)

5. Individual preparation
• Preparing for the review meeting by reviewing the document(s)
6. Noting potential defects, questions and comments
7. Examination/evaluation/recording of results (review meeting):
• Discussing or logging, with documented results or minutes (for more formal
review types)
• Noting defects, making recommendations regarding handling the defects,
making decisions about the defects

14
Activities of a Formal Review continued…

8. Examining/evaluating and recording during any physical meetings or tracking any

group electronic communications
9. Rework
10. Fixing defects found (typically done by the author)
• Recording updated status of defects (in formal reviews)
11. Follow-up:
• Checking that defects have been addressed
• Gathering metrics
12. Checking on exit criteria (for more formal review types)

15
Roles and Responsibilities

• Manager: decides on the execution of reviews, allocates time in project schedules

and determines if the review objectives have been met.

• Moderator: the person who leads the review of the document or set of
documents, including planning the review, running the meeting, and following-up
after the meeting. If necessary, the moderator may mediate between the various
points of view and is often the person upon whom the success of the review rests.

• Author: the writer or person with chief responsibility for the document(s) to be
reviewed.

16
Roles and Responsibilities continued…

• Reviewers: individuals with a specific technical or business background (also

called checkers or inspectors) who, after the necessary preparation, identify and
describe findings (e.g., defects) in the product under review. Reviewers should be
chosen to represent different perspectives and roles in the review process, and
should take part in any review meetings.

• Scribe (or recorder): documents all the issues, problems and open points that
were identified during the meeting.

17
Checklists can help

Looking at software products or related work products from different perspectives and
using checklists can make reviews more effective and efficient.

For example, a checklist based on

various perspectives such as user,
maintainer, tester or operations,
or a checklist of typical requirements
problems may help to uncover
previously undetected issues.

18
Types of Reviews

1. Informal Review
2. Walkthrough
3. Technical Review
4. Inspection

• You can use more than one type of review for a single work product
For example you might hold…
an informal review before a technical review
and then an inspection on a requirements specification
And finally a walkthrough with customers.

19
Informal Review

• No formal process
• May take the form of pair programming or a technical lead reviewing designs and
code
• Results may be documented
• Varies in usefulness depending on the reviewers

• Main purpose: inexpensive way to get some benefit

Example: Issue the test strategy document via email to a group for comments.
• No formal tracking of comments or updates
• Suggestion may or may not be taken on board
20
Walkthrough

• Meeting led by author of the document/item

• May take the form of scenarios, dry runs, peer group participation
• Open-ended sessions
• Optional pre-meeting preparation of reviewers
• Optional preparation of a review report including list of findings
• Optional scribe (who is not the author)
• May vary in practice from quite informal
to very formal
• Main purposes: learning, gaining understanding, finding defects

21
Technical Review

• Documented, defined defect-detection process that includes peers and technical

experts with optional management participation
• May be performed as a peer review without management participation
• Ideally led by trained moderator (not the author)
• Pre-meeting preparation by reviewers
• Optional use of checklists

22
Technical Review continued..

• Preparation of a review report which includes the list of findings, the verdict
whether the software product meets its requirements and, where appropriate,
recommendations related to findings
• May vary in practice from quite informal to very formal
• Main purposes: discussing, making decisions, evaluating alternatives, finding
defects, solving technical problems and checking conformance to specifications,
plans, regulations, and standards

23
Inspection

• Led by trained moderator (not the author)

• Usually conducted as a peer examination
• Defined roles
• Includes metrics gathering
• Formal process based on rules and checklists
• Specified entry and exit criteria for acceptance of the software product

24
Inspection continued..

• Pre-meeting preparation
• Inspection report including list of findings
• Formal follow-up process
• Optional process improvement components
• Optional reader
• Main purpose: finding defects

25
Success Factors for Reviews

• Success factors for reviews include:

• Each review has clear predefined objectives.
• The right people for the review objectives are involved.
• Defects found are welcomed and expressed objectively.
• People issues and psychological aspects are dealt with (e.g., making it a
positive experience for the author).
• The review is conducted in an atmosphere of trust; the outcome will not be
used for the evaluation of the participants.

26
Success Factors for Reviews continued..

• Review techniques are applied that are suitable to achieve the objectives.
• Checklists or roles are used if appropriate to increase effectiveness of defect
identification.
• Training is given in review techniques, especially the more formal techniques
such as inspection.
• Management supports a good review process (e.g., by incorporating adequate
time for review activities in project schedules).
• There is an emphasis on learning and process improvement.

27
Static Analysis by Tools
Static Analysis by Tools

• Static analysis can locate defects that are hard to find in dynamic testing. As with
reviews, static analysis finds defects rather than failures.
• Static analysis tools analyze program code (e.g., control flow and data flow –
defined on next slide), as well as generated output such as HTML and XML

• They don’t execute the code!

• They look for defects in the source code
or software model

29
Control Flow and Data Flow Definitions

• control flow analysis: A form of static analysis based on a representation of

unique paths (sequences of events) in the execution through a component or
system. Control flow analysis evaluates the integrity of control flow structures,
looking for possible control flow anomalies such as closed loops or logically
unreachable process steps.
• Example: helps find dead code that can never logically be executed

• data flow analysis: A form of static analysis based on the definition and usage of
variables.
• Example: helps find inconsistencies where a variable is defined, but isn’t used

30
The Value of Static Analysis

• Early detection of defects prior to test execution

• Early warning about suspicious aspects of the code or design by the calculation of
metrics, such as a high complexity measure
• Cyclomatic Complexity (CC)

• Identification of defects not easily found by dynamic testing

• Detecting dependencies and inconsistencies in software models such as links
• Improved maintainability of code and design
• Prevention of defects, if lessons are learned in development

31
Typical Defects Found

• Typical defects discovered by static analysis tools include:

• Referencing a variable with an undefined value
• Inconsistent interfaces between modules and components
• Variables that are not used or are improperly declared (= data flow)
• Unreachable (dead) code (=control flow)
• Missing and erroneous logic (potentially infinite loops)
• Overly complicated constructs
• Programming standards violations
• Security vulnerabilities
• Syntax violations of code and software models

32
Who uses Static Analysis Tools?

• Static analysis tools are typically used by developers (checking against predefined
rules or programming standards) before and during component and integration
testing or when checking-in code to configuration management tools, and by
designers during software modeling.

• Static analysis tools may produce a large number of warning messages, which
need to be well-managed to allow the most effective use of the tool.

• Compilers may offer some support for static analysis, including the calculation of
metrics.

33
Example Static Analysis Tool - Jtest

• Organisation ParaSoft Corporation

http://www.parasoft.com/
• Software Description Jtest is an automatic static analysis and unit testing tool for
Java development. With the click of a button, Jtest automatically enforces over
300 industry-respected coding standards, allowing organizations to prevent the
most common and damaging errors. Jtest reduces time spent chasing and fixing
bugs by automatically generating unit test cases that test code construction and
functionality, and performs regression testing to ensure that no new errors have
been introduced into code.

Source: http://www.testingfaqs.org/t-static.html#Jtest

34
Example Static Analysis Tool - STATIC

• Organisation Software Research, Inc.

http://www.soft.com/TestWorks/
• Software Description Working as a stand-alone product or as part of the tool
suite, STATIC provides more comprehensive syntax and semantic analysis for C
programs than most compilers, including locating non-portable constructs and
dead code. STATIC also searches the entire program for inconsistencies across the
modules that comprise an application. This feature is especially important when
analyzing code in multi-programmer projects. STATIC processes a code file or
multiple files and generates a report covering more than 300 possible syntactical,
warning and informational messages.
Source: http://www.testingfaqs.org/t-static.html#Jtest

35
Can you answer these questions?

Which of statements below best describes static testing?

A. Static testing executes software to find defects early.

B. Static testing is best applied against code for maximum benefit
C. Static testing is a manual technique to find defects.
D. Static testing techniques do not execute code and are used to detect
defects early in the software life cycle.

36
Can you answer these questions?

A technical review is best for?

A. Gaining an understanding as an inexpensive review.

B. Evaluating standards with mandatory management participation
C. Making decisions, evaluating alternatives and checking conformance to
standards.
D. Formal walkthroughs without peers

37
Can you answer these questions?

What sort of defects are not detected by static analysis tools?

A. Unreachable code
B. Performance problems
C. Inconsistent interfaces between modules
D. Programming standards
E. Security vulnerabilities

38
ISTQB Practice Exam Question

Which one of the following examples describes a typical benefit of static analysis
supported by tools?
A. Static analysis supported by tools may find defects prior to manual test
execution.
B. Static analysis supported by tools prevents business analysts and requirement
engineers building software models (e.g. state transition diagrams), which do not
match the requirements.
C. By using static analysis tools user acceptance testing can be shortened because
the users need to execute less tests.
D. By performing static analysis of the code supported by tools the need for the
developers doing unit testing is decreased.

39
References :

• Reference: ISTQB Certified Tester Foundation Level Syllabus,

Version 2010, pp30-35