tfrhhduhjhj

1. Capgemini Financial Services
Independent Test Engineering and Monitoring Solutions
ISTQB Foundation Level
Chapter- 3 Static techniques

2. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Agenda
1. Static and Dynamic techniques.
2. Review process
3. Static analysis by tools

3. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Static and Dynamic techniques.
StaticStatic DynamicDynamic
StructuralStructural
BehaviouralBehavioural
FunctionalFunctionalNon-functionalNon-functional
ReviewsReviews
WalkthroughsWalkthroughs
Desk-checkingDesk-checking
Data
Flow
Data
Flow
Symbolic
Execution
Symbolic
Execution
Definition
-Use
Definition
-Use
StatementStatement
Branch/DecisionBranch/Decision
Branch ConditionBranch Condition
Branch Condition
Combination
Branch Condition
Combination
LCSAJLCSAJ
ArcsArcs
Equivalence
Partitioning
Equivalence
Partitioning
Boundary
Value Analysis
Boundary
Value Analysis
Cause-Effect GraphingCause-Effect Graphing
Rando
m
Rando
m
UsabilityUsability
PerformancePerformance
Static AnalysisStatic Analysis
InspectionInspection
Control
Flow
Control
Flow
etc.etc.
etc.etc.
etc.etc.
etc.etc.
etc.etc.
State
Transition
State
Transition

4. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Reviews


 Review

5. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Review Definition
IEEE Standard Glossary of SE Terminology:
A process or meeting during which a work product, or a set of work
products, is presented to project personnel, managers, users,
customers, or other interested parties for comment or approval.
Types include code review, requirements review etc.
Reviews

6. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Review:
− Presentation of each SW Component to the Group
in each Development Phase
− Discussion and Coordination with other components
− Goal:Goal:
Clarification and Accept/Reject DecisionClarification and Accept/Reject Decision
Reviews

7. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
 Reviews are applied at various points during software
development and serve to uncover errors and defects
that can then be removed.
 Software reviews are a “filter” for the software
engineering process.
 Software review “purify" the software engineering
activities that we have called analysis, design and
coding.
Reviews

8. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
 A review – any review – is a way of using the
diversity of a group of people to :
 Point out needed improvements in the product of a single
person or team.
 Confirm those part of the product in which improvement is
either not desired or not needed.
 The main goal is to identify defects within the stage or phase of
the project where they originate,rather than in later test stages;
this is referred to as “stage containment.”
Reviews

9. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Roles and responsibilities
A typical formal review will include the roles below:
 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 follow-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.

10. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Roles and responsibilities
Author: the writer or person with chief responsibility for the
document(s) to be reviewed.
 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 they take part in any review meetings.
 Scribe (or recorder): documents all the issues, problems and
open points that were identified during the meeting.

11. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
The Players
reviewreview
leaderleader
producerproducer
recorderrecorder reviewerreviewer
standards (SQA)standards (SQA)
user repuser rep

12. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Conducting the Review
be prepared—evaluatebe prepared—evaluate
product before the reviewproduct before the review
review the product, notreview the product, not
the producerthe producer
keep your tone mild, askkeep your tone mild, ask
questions instead ofquestions instead of
making accusationsmaking accusations
stick to the review agendastick to the review agenda
raise issues, don't resolve themraise issues, don't resolve them
avoid discussions of style—stick to technicalavoid discussions of style—stick to technical
correctnesscorrectness
schedule reviews as project tasksschedule reviews as project tasks
record and report all review resultsrecord and report all review results
1.1.
2.2.
3.3.
4.4.
5.5.
6.6.
7.7.
8.8.

13. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
What Can You Review?
Anything written down on paper!
 • Code reviews are just a starting point
Examples of things that can and should be reviewed:
 • Requirements
 – Catching problems here can save huge amounts of
time/money later
 • Design
 • Test plans
 • Test results
 • Implementation
 • Process plans
 • …
•

14. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Life Cycle Applications
Types and methods of reviews will normally be
specified in the Software Development Plan or Program
Management Plan. Some are dictated by a contract.
Reviews consist of three parts:
 Planning
 Review Conduct
 Post-Review
All three are very important for a successful review
Life Cycle Applications

15. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Planning Phase
Stating purpose of the review
Selecting and arranging participants
Distribution of review material
 Provide ahead of time
Setting physical location
Preparing an agenda
Planning Phase

16. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Conduct Phase
Keeping to the agenda
Remember, the purpose of the review is to identify the
problems and assign action for their resolution, not
fixing the problems themselves
Review leader/moderator must maintain control
Scribe/recorder puts proceedings into written form
Conduct Phase

17. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Post-Review Phase
Depends on the actions required
Progress on AIs may be reported at the next review
Unsatisfactory results of a review may require another
one
Post-Review Phase

18. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Reviews
Types of review
 Informal review
 Walkthrough
 Technical review
 Inspection

19. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Informal review
Key characteristics:
 No formal process;
 There may be pair programming or a technical lead
reviewing designs and code;
 optionally may be documented;
 May vary in usefulness depending on the reviewer;
 Main purpose: inexpensive way to get some benefit.

20. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Walkthrough
Key characteristics:
 Meeting led by author;
 Scenarios, dry runs, peer group;
 Optionally a pre-meeting preparation of reviewers,
review report, list of findings and scribe
(who is not the author)
 May vary in practice from quite informal to very
formal;
 Main purposes: learning, gaining understanding, defect
finding.

21. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Technical review
 Key characteristics:
 Documented, defined defect-detection process that includes peers and
technical experts;
 May be performed as a peer review without management participation;
 Ideally led by trained moderator (not the author);
 Pre-meeting preparation;
 Optionally the use of checklists, review report, list of findings and
management participation;
 May vary in practice from quite informal to very formal;
 Main purposes: discuss, make decisions, evaluate alternatives, find defects,
solve technical
 problems and check conformance to specifications and standards.

22. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection
Key characteristics:
 Led by trained moderator (not the author);
 Usually peer examination;
 Defined roles;
 Formal process based on rules and checklists with entry and exit
criteria;
 Pre-meeting preparation;
 Inspection report, list of findings;
 Formal follow-up process;
 Optionally, process improvement and reader;
 main purpose: find defects.

23. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Review formality spectrum



24. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Comparison

25. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Review activity

26. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection - Objectives
Defect Detection
Documents are checked for
cleanness and consistency against rules
Defect Prevention
Learning from defects found
Suggesting improvements
On the Job Training
Education in standards and rules

27. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection
 Inspection Process

 1. Planning 4. Meeting
 2. Overview 5. Rework
 3. Preparation 6. Follow-up

28. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection
 1. Planning
 • Schedules
 • Participants
 • Materials

29. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection
 2. Overview
 Objectives:
 • Provide educational background to
 understand materials
Description:
 • Presentation by author of work to be
 inspected

30. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection
3. Preparation
 • Objectives -Prepare participants to identify
 defects.
 • Description -Individually study inspection
 material.

31. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Inspection
 4. Inspection Meeting
 1. Introduce meeting - moderator reminds people of the roles
 2. Establish preparedness - moderator confirms inspectors
 prepared
 3. Review inspection checklist - confirms all items on check
list studied
 4. Read product and record defects - reader reads, inspectors
 raise defects, discussion, recorder records the defects
 5. Review the defect list - review the defect list for
completeness
 Make final decision - accept, verify rework, re-inspect

32. Overview | Financial Services
All work described was performed by Capgemini or a Capgemini affiliate
Static analysis by tools

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 examined by the tool;
dynamic testing does execute the software code.
Typical defects discovered by static analysis tools include:
»referencing a variable with an undefined value;
»inconsistent interface between modules and components;
»variables that are never used;
»unreachable (dead) code;
»programming standards violations;
»security vulnerabilities;
»syntax violations of code and software models.

33. Thank You