1
Maveric Systems Limited
Section 3 – Static techniques
Version 1.0
ISEB Foundation Certificate in Software Testing
Copyright © Maveric Systems 2006
2
Presentation Coverage
• Reviews and the Test Process
• The Review Process
• Static Analysis By Tools
Copyright © Maveric Systems 2006
3
Reviews And Test Process
Copyright © Maveric Systems 2006
4
Definition
Static Testing
•Testing of a component or system at specification or
implementation level without execution of that software, e.g.,
reviews or static code analysis
•The process of evaluating a system or component based on its
form, structure, content, documentation
Dynamic Testing
•Testing that involves the execution of the software of a
component or system
Copyright © Maveric Systems 2006
5
Static Testing in SDLC
Copyright © Maveric Systems 2006
6
What is Review?
• An evaluation of a product or project status to ascertain
discrepancies from planned results and to recommend
improvements
• Review is “A retrospective view or survey”
• Review is a process during which a work product – Is
presented to interested parties for comment or approval
Copyright © Maveric Systems 2006
7
Why Review?
• Effective means of isolating incidents
• Isolating incidents at an early stage of development
• Saving substantial time and cost to the development
Copyright © Maveric Systems 2006
8
When to Review?
Review should happen as soon as possible after the item to
be tested has been created
USE
Correctable fault CODING
Cost of
fault
escalates
Major redesign DESIGN
REQUIREMENT
Hidden error SPECIFICATION
Copyright © Maveric Systems 2006
9
What to Review?
• Any document can be subjected to review
• Requirement specification, design specification, code,
test plans, user guides, etc.
• Reviews can also be done for process improvements
Copyright © Maveric Systems 2006
10
Benefits of Review
• Reduce lifetime cost
• Early detection of defects
• Identify omitted requirements
and design errors
• Reduce development timelines
• Identify deviation from standards
and reduce fault levels
• Can require 15% of development
budget and save 35% to 50% of
development time
Copyright © Maveric Systems 2006
11
Review Process
Copyright © Maveric Systems 2006
12
Phases of a Formal Review
• Planning
̶ Selecting the personnel and role allocation
̶ Defining entry and exit criteria
• Kick-off
̶ Explaining objective
̶ Distribution of documents
• Checking entry criteria
• Individual Preparation
̶ Done by each participant
Copyright © Maveric Systems 2006
13
Phases of a Formal Review (CONTD.)
• Review Meeting
̶ Document defects
̶ Prepare Minutes of Meeting
• Rework
̶ Fixing defects found
• Follow-up
̶ Check that defects are fixed
̶ Gathering metrics
̶ Ensure exit criteria are met
Copyright © Maveric Systems 2006
14
Roles in Review
• Manager
• Moderators
• Author
• Reviewers / inspectors
• Recorder / Scribe
Copyright © Maveric Systems 2006
15
Types of Review
• Walkthrough
• Inspection
• Informal Review
• Technical review
Copyright © Maveric Systems 2006
16
Walkthrough
• Purpose : Understanding design and code,
finding defects
• A step-by-step presentation by the author of
a document in order to gather information
and to establish a common understanding of
its content
• Little or no preparation is usually required
• Led by author. Peers are other participants
• Dry runs of design, code and test cases
Copyright © Maveric Systems 2006
17
Inspection
• A type of peer review that relies on visual
examination of documents to detect defects
• A group review quality process for
̶ Product & Process improvement
• Main purpose is to find defects such as
violations of development standards and
non-conformance to higher level
documentation
• Led by moderator
• Reader, Recorder, Author and Inspector are
other participants
• Formal review process
Copyright © Maveric Systems 2006
18
Informal Review
• Unplanned and undocumented
• Find problems quickly and cheaply
• No Formal Process
• Varies in usefulness depending on the reviewer
Copyright © Maveric Systems 2006
19
Technical Review
• Purpose: Understanding design and code,
finding defects
• A step-by-step presentation by the author of a
document in order to gather information and to
establish a common understanding of its content
• Little or no preparation is usually required
• Led by author. Peers are other participants
• Dry runs of design, code and test cases
Copyright © Maveric Systems 2006
20
Comparison of Review Types
Review type Primary Led by Participants
purpose
Walkthrough Educational or Author Peers
Informational
Inspection Finding faults Moderator Reader,
and process Recorder,
improvement Author,
Inspector
Informal Find problems Not defined Not defined
review quickly and
cheaply
Technical Finding faults Chairperson Peers, technical
review experts
Copyright © Maveric Systems 2006
21
Success Factors for Reviews
• Clear predefined objective
• Right people for the objective in hand
• Express defects objectively
• Defects found should be welcomed
• Review the product, not the person
• Choose the appropriate review technique
• Checklist is used to increase effectiveness of
defect identification
• Management support
• Emphasis on learning and Process Improvement
Copyright © Maveric Systems 2006
22
Static Analysis by Tools
Copyright © Maveric Systems 2006
23
Static Analysis by Tools
• Analysis of a program carried out without
executing the program
• Static analysis can detect possible faults such as
̶ Unreachable code
̶ Undeclared variables
̶ Parameter type mismatches, etc.
Copyright © Maveric Systems 2006
24
Static Analysis by Tools (CONTD.)
• Values of Static analysis
̶ Early detection of defects prior to test execution
̶ Identification of defects not easily found by dynamic testing
̶ Improved maintainability of code and design
̶ Detecting dependencies and inconsistencies in software model
• Types of Defects discovered
̶ Undefined variable referencing
̶ Inconsistent interface between modules / components
̶ Redundant / unused variables
̶ Standards violation
̶ Syntax violations of code and model
̶ Security vulnerabilities
Copyright © Maveric Systems 2006
25
Static Analysis by Tools (CONTD.)
Techniques Used by Static Analysis Tools:
•Semantic checking
•Strong type checking
•Memory allocation checking
•Logical statement checking
•Interface and include problem checking
•Security checking
•Metrics
•Crawl source code
Copyright © Maveric Systems 2006
26
Static Analysis by Tools (CONTD.)
Copyright © Maveric Systems 2006
27
Compilers
• A computer program that translates
code expressed in a higher order
language into their machine code
equivalents
• Compiler finds fault in the syntax using
static analysis
• Many compilers also provide
information on variable use
Copyright © Maveric Systems 2006
28
Data Flow Analysis
• A form of static Analysis based on the
definition and usage of variables
• Considers the use of data on paths
through the code
• ‘Definitions’ and ‘Use’
̶ Data definition – use pair
̶ Data definition – ‘C’ use pair
̶ Data definition – ‘P’ use pair
Copyright © Maveric Systems 2006
29
Control Flow Graph
• Control flow graph is defined as a diagrammatic
representation of the possible alternative
control flow paths through a component
• It is an abstract data structure used in
compilers
• It is an abstract representation of a procedure
or program, maintained internally by a
compiler
Copyright © Maveric Systems 2006
30
Control Flow Graph (CONTD.)
Entry 1 if (y<0)
pow=0-y; 2 3 else pow=y
4 z=1.0
while (pow !=0)
5
z=z*x
6 7 if (y<0)
pow=pow-1;
z=1.0/z 8 9 printf(z)
Exit
Copyright © Maveric Systems 2006
31
Complexity Metrics
• ‘Complexity’ can be defined as the degree to
which a system or component has a design or
implementation that is difficult to understand
and verify
• The metrics used to arrive at this complexity
are called complexity metrics
• Lines of code, Cyclomatic complexity
Copyright © Maveric Systems 2006
32
Conclusion
Contents covered
•Review and the Test Process
•Static Review Process
•Static review techniques
•Static Analysis
•Static Analysis using Tools
Copyright © Maveric Systems 2006
