I

ISTQB Foundation Level

Chapter 3: Static Techniques

• Static Techniques and the Test Process

• Review Process
• Static Analysis by Tools
Part Of Static Testing
Static Vs. Dynamic Techniques
Static Testing
 Examples
Almost any work product can be examined using static testing, for example:

1. Specifications, including business requirements, functional requirements, and security

requirements.

2. Epics, user stories, and acceptance criteria.

3. Architecture and design specifications.

4. Testware, including test plans, test cases, test procedures, and automated test scripts

5. User guides , Contracts, project plans, schedules, and budgets.

6. Models(UML), such as activity diagrams and use case .

Defect Cost
Abstraction
 Review Process
• The formality of a review and the way it’s done depend on the objective,
the development process, and the existence of regulatory requirements.
Formal Review Activities >>

• Planning

• Initiate review

• Individual review

• Issue communication and analysis(Review meeting )

• Fixing and reporting

 Planning Review
• Defining the scope, which includes the purpose of the review, what documents
or parts of documents to review, and the quality characteristics to be evaluated.

• Estimating effort and timeframe.

• Identifying review characteristics such as the review type with roles, activities,
and checklists.

• Selecting the people to participate in the review and allocating roles.

• Defining the entry(Start)and exit(Stop) criteria for more formal review types
(e.g., inspections).

100 Req. >>

 Initiate review
• Distributing the work product and other material, such as issue log
forms, checklists, and related work products.

• Explaining the scope, objectives, process, roles, and work products to

the participants.

• Answering any questions that participants may have about the review.
 Individual review

• i.e. individual preparation.

• Reviewing all or part of the work product.

• Noting potential defects, recommendations, and questions.

 Issue communication and analysis ( review meeting)
• Communicating identified potential defects (e.g. in a review meeting).

• Analyzing potential defects, assigning ownership and status to them.

• Evaluating and documenting quality characteristics.

• Evaluating the review findings against the exit criteria to make a review
decision (reject; major changes needed; accept, possibly with minor
changes).
 Fixing and reporting
• Creating defect reports for those findings that require changes.

• Fixing defects found (done by the author) in the work product reviewed.

• Communicating defects to the appropriate person or team.

• Recording updated status of defects in formal reviews.

• Collection metrics and graph.

• Checking that exit criteria are met.

• Accepting the work product when the exit criteria are reached.
 Roles and Responsibilities in a formal review
Roles Responsibilities
Author • Creates the work product under review
• Fixes defects in the work product under review
Manager • Review planning and execution of reviews
• Assigns staff, budget, and time
• Monitors ongoing cost-effectiveness
• Executes control decisions
Facilitator (moderator) • Ensures effective running of review meetings
• Mediates, between the different points of view
• Person upon whom the success of the review
depends
Review leader • Takes overall responsibility for the review
• Decides who will be involved and organizes when
and where it will take place
Reviewers • Experts, persons working on the project,
stakeholders
• Identify potential defects in the work product
under review
Scribe (recorder) • Collates potential defects found during the
individual review activity
• Records new potential defects.
Types of Reviews
 Informal review

• (e.g., buddy check, pair review)

• Main purpose: detecting potential defects

• Generating new ideas or solutions, quickly solving minor problems

• Not based on a formal (documented) process

• May not involve a review meeting

• Very commonly used in Agile development

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

• exchanging ideas about techniques, training of participants

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

• Scribe is mandatory

• Checklists and Individual preparation is optional

 Technical review
• Main purposes: detecting potential defects
• evaluating quality and building confidence in the work product
generating new ideas
• motivating authors to improve future work products
• Reviewers should be technical persons
• Review meeting and Individual preparation is required
• checklist is optional
• Scribe is mandatory, not the author
 Inspection
• Main purposes: detecting potential defects, evaluating quality and building
confidence in the work.
• Preventing future similar defects through author learning and root cause
analysis.
• motivating authors to improve future work products and the software
development process
• Follows a defined process with formal documented outputs, based on rules
and checklists
• Uses clearly defined roles and Individual preparation is mandatory !

• the BEST option to choose when the review must follow a formal process
based on rules and checklists
Peer Review
• The types of reviews described above can be done as peer review i.e.
done by colleague on the same organization level , All of tester , all of
seniors developer or all of leaders
Applying Review Techniques
• Ad hoc ()
• Checklist-based(HLD)
• Scenarios(LLD) and dry runs(Checking use case)
• Role-based (End user) single
• Perspective-based (different )
 Ad hoc
• Reviewers are provided with little or no guidance on how this task
should be performed.

• Needing little preparation

• Dependent on reviewer skills

• lead to many duplicate issues being reported by different reviewers

because no communication between team.
 Checklist-based (Risk)<<HLD
1.Pas
• Reviewers detect issues based on checklists that are distributed at initiate 2.Pas
review(e.g., by the facilitator). 3.Pas
4
5
6
• Consists of a set of questions and goals based on potential defects.
(3/6)*
• Then compare between Checklist and product.

• Checklists should be specific to the type of work product under review and
should be maintained regularly.

• Advantage :systematic coverage of typical defect types.

 Scenarios and dry runs (LLD)

• Reviewers are provided with structured guidelines on how to read

through the work product.

• Work product should be good documented.

• Provide more details of checklist but need more time.

• supports reviewers in performing “dry runs” on the work product by

checking use cases.
 Role-based

• Reviewers evaluate the work product from the perspective of individual

stakeholder roles.

• Roles include specific end user types (experienced, inexperienced, senior,

child, etc.)

• Specific roles in the organization (user administrator, system

administrator etc.).
Perspective-based

• Similar to a role-based review

• reviewers take on different stakeholder viewpoints in individual reviewing

included end user, marketing, tester..etc.

• Using different stakeholder viewpoints leads to more depth in individual

review with less duplication of issue.

• More effective technique for reviewing requirement and product.

 Success Factors for Reviews
• Each review has clear objectives, defined during review planning.

• Review types are applied which are suitable to achieve the objectives

• Any review techniques used, such as checklist-based or role-based reviewing, are suitable for defect identification in the
work product.

• Checklists used address the main risks and are up to date.

• Large documents are written and reviewed in small chunks to get frequent feedback on defects.
100 req.
20 req. >>
20 req.
20 .
20
20.
• Reviews are scheduled.

• Participants have good time to prepare.

• Manger support the review process.

 People-related success factors for reviews include:
• The right people are involved to meet the review objectives.

• Involved Testers >> QC

• Participants have good time and attention to details.

• Meeting is well managed.

• Reviews are conducted on small chunks, so that reviewers do not lose focus
during individual review and/or the review meeting.
20<< 20 << 20 <<
• Defects found are should be handled objectively.
People-related success factors for reviews
include:
• Avoid body language.

• Training is provided, especially for formal review type.

• The review is conducted in an atmosphere of trust .

• A culture of learning and process improvement.

 Static Analysis By Tools

• Analysis of program code (Such as, Control flow and dataflow), as well
as the generated output (Such as, HTML and XML) by supporting tool.

• Apply on code or models.

• Important part of security testing.

• For developer or automation tester.

Data flow analysis
Unreachable code example
Cyclomatic complexity

• measure of the complexity of flow graph.

• The more complex the flow graph, the greater the measure

• Calculated as: complexity = number of decisions + 1

 Example

IF A=360
THEN IF B>C
THEN A=B
ELSE A=C
ENDIF
ENDIF
Print A

In the program mentioned above has 2 IF conditions. Thus just add 1 to

it and the cyclomatic complexity is 2+1=3
Samples of Static Analysis Tools
 Chapter4: Test Design Techniques

• The Test Development Process

• Categories of Test Design Techniques
• Specification Based (Black Box) Techniques
• Structure Based (White Box) Techniques
• Experience-Based Techniques
• Choosing a Test Technique
 Categories of Test Techniques

• The purpose of a test technique, is to help in identifying test conditions,

test cases, and test data.

0 >>49 = F
50 >> 100 = P
Test Design Techniques Differences
 characteristics of Test Design Techniques

Techniques Characteristics

Black-box Requirements-Use Cases-User Stories

White-box Architecture analysis-Detailed Design-Internal Structure-Code

Experience-based Knowledge of (Testers-Developers-Users)

Types of Test Design Techniques
 Specification-Based Techniques (Black-box )

• Equivalence Partitioning- Classes

• Boundary Value Analysis

• Decision Table Testing

• State Transition Testing

• Use Case Testing

 1) Equivalence Partitioning
• Equivalence partitions for both valid and invalid values.

• Valid values are values that should be accepted by the component or

system. called a “valid equivalence partition

• Invalid values are values that should be rejected by the component or

system. called an “invalid equivalence partition.

• Partitions can be identified for any data element related to the test
object, including inputs, outputs, internal.
Equivalence Partitioning
• Any partition may be divided into sub partitions if required

• To achieve 100% coverage with this technique, test cases must cover
all identified partitions (including invalid partitions) by using a
minimum of one value from each partition.

• Equivalence partitioning is applicable at all test levels.

 Example (1)
Testing an input box accepting numbers from 1 to 1000

• Divide the input into three classes

1-Valid input: a single input value between 1 and a 1000

2-Invalid input less than 1: any single input<1
3-Invalid input more than 1000: any single input > 1000
 Example(2)
• For example consider a program with two input variables size and
weight:
• valid ranges:

S1: 0 < size < 200

W1: 0 < weight < 1500

• invalid ranges:
S2 : size  200
S3 : size  0
W2 : weight  1500
W3 : weight  0
Test Cases
 Example(3)
A savings account in a bank earns a different rate of interest depending on
the balance in the account:

• A balance between $0 up to $100 has 3% interest rate

• A balance over $100 and up to $1000 has a 5% interest rate
• A balance over $1000 has a 7% interest rate
2) Boundary Value Analysis
• Select test cases of inputs on the boundaries, just above and below
boundaries.

• The minimum and maximum values of a partition are its boundary

values.

• Boundary value analysis (BVA) is an extension of equivalence

partitioning, but can only be used when the partition is ordered.
Boundary Value Analysis
• BVA identify three boundary values per boundary : the values before,
at, and just over the boundary
Example(1)
Age of Driving License Applicant should be Greater than or Equal 18,
and Less than or Equal 60.
Example(2)
Testing an input box accepting numbers from 1 to 1000
• Choose the boundaries: 1,1000
• Below and above the boundaries: 999,1001, 2,0
3) Decision Tables
• Each column corresponds to a decision rule that defines a unique
combination of conditions which results in the execution of the
actions associated with that rule.

• The values of the conditions and actions are usually shown as Boolean
values (true or false) or discrete values (e.g., red, green, blue), but can
also be numbers or ranges of numbers.
Decision Tables
Decision Table Structure
 Example(1)
• Conditions
1-Employee Type : S and H
2- Hours Worked <40 , =40 , >40
The maximum number of rules = 2 x3
 Example(2)
• A marketing company treats clients according to three characteristics:
• Gender
• City Resident
• Age group: A (under 30), B (between 30 and 60), C (over 60).

• The company has four products (W, X, Y and Z) to test market.

• Product W for male city Resident
• Product X for young males.
• Product Y for middle aged Female who do not live in cities.
• Product Z will to all but older males.
1. Identify Conditions & Values
• The three data attributes tested by the conditions in this problem are

• gender, with values M and F;

• city resident, with value Y and N; and
• age group, with values A, B, and C

• Values as stated in the problem.

2. Compute Maximum Number of Rules
The maximum number of rules is:
2 x 2 x 3 = 12
3. Identify Possible Actions
• The four actions are:
• market product W,
• market product X,
• market product Y,
• market product Z.
4. Enter All Possible Rules
5. Full table
 6)Transform the Rules into Test Cases.

Test Case Id’s Sex City Age Expected Result

1 M Y A W,X,Z
2 F Y A Z
3 M N A X,Z
4 F N A Z
5 M Y B W,Z
6 F Y B Z
7 M N B Z
8 F N B Y,Z
9 M Y C W
10 F Y C Z
11 M N C
12 F N C Z
 4) State Transition Testing
• A state transition diagram shows the possible software states, as well as how the
software enters, exits, and transitions between states.

• A transition is initiated by an event (e.g., user input of a value into a field). The
event results in a transition.

• A state transition table shows all valid transitions and potentially invalid
transitions between states.

• Coverage is commonly measured as the number of identified states or transitions

tested.
State Transition Testing
State Transition Testing
How many Test cases are required to cover all states ? 2
How many Test cases are required to cover all transitions? 4
 Use Case Testing
• Use cases are associated with actors (human users, external hardware, or
other components or systems) and subjects (the component or system to
which the use case is applied).

• Each use case specifies some behavior that a subject can perform in
collaboration with one or more actors .

• A use case can be described by interactions and activities, as well as

preconditions, postconditions and natural language where appropriate.
 Use Case Testing
• A use case can include possible variations of its basic behavior, including
exceptional behavior and error handling.

• Coverage can be measured by the percentage of use case behaviors

tested divided by the total number of use case behaviors
Use Case Model Components

Used in gathering Requirements

Use Case Testing

Testing the WHOLE System Start-to-End, not Individual parts

Example
An employee’s bonus is to be calculated. It cannot be negative, but it can be
calculated down to zero. The bonus is based on the length of employment.

The categories are: less than or equal to 2 years, more than 2 years but less
than 5 years, 5 or more years but less than 10 years, 10 years or longer.

What is the minimum number of test cases required to cover all valid
equivalence partitions for calculating the bonus?

A.3
B.5
C.2
D.4
You are testing a machine that scores exam papers and assigns grades.
Based on the score achieved the grades are as follows:

1-49 = F, 50-59 = D-, 60-69 = D, 70-79 = C, 80-89 = B, 90-100=A

If you apply equivalence partitioning, how many test cases will you need to achieve
minimum test coverage?

A. 6

B. 8

C. 10

D. 12
A video application has the following requirement: The application shall allow playing a
video on the following display sizes:
• 1. 640x480.
• 2. 1280x720.
• 3. 1600x1200.
• 4. 1920x1080.
Which of the following list of test cases is a result of applying the Equivalence Partitioning
test technique to test this requirement?

A. Verify that the application can play a video on a display of size 1920x1080 (1 test)
B. Verify that the application can play a video on a display of size 640x480 and 1920x1080 (2
tests).
C. Verify that the application can play a video on each of the display sizes in the
requirement (4 tests)
D. Verify that the application can play a video on any one of the display sizes in the
requirement (1 test)
Which of the following is an extension of equivalence partitioning?

A. Decision Tables
B. Decision testing
C. Boundary value analysis
D. State transition testing
A speed control and reporting system has the following characteristics:

•If you drive 50 km/h or less, nothing will happen.

•If you drive faster than 50 km/h, but 55 km/h or less, you will be warned.
•If you drive faster than 55 km/h but not more than 60 km/h, you will be fined.
•If you drive faster than 60 km/h, your driving license will be suspended.

Which would be the most likely set of values (km/h) identified by two-point
boundary value analysis?

A.0, 49, 50, 54, 59, 60

B.50, 55, 60
C.49, 50, 54, 55, 60, 62
D.50, 51, 55, 56, 60, 61
You are testing a machine that scores exam papers and assigns grades. Based on
the score achieved the grades are as follows:

1-49 = F, 50-59 = D-, 60-69 = D, 70-79 = C, 80-89 = B, 90-100=A

If you apply boundary value analysis, how many test cases will you need to
achieve minimum test coverage?

A. 8

B. 10

C. 12

D. 14
Which of the following is the correct decision table for the following code for
ordering a hamburger ?

Note : if you add or delete items from

the basic burger, you no longer get the basic burger.
 Table 1

Table 2
 Table 3

Table 4
Which of the following statements about the given state transition diagram and
table of test cases is TRUE?

A. The given test cases can be used to cover both valid and invalid transitions in
the state transition diagram

B. The given test cases represent all possible valid transitions in the state
transition diagram

C. The given test cases represent only some of the valid transitions in the state
transition diagram.

D. The given test cases represent sequential pairs of transitions in the state
transition diagram
For the following state transactions diagram , how many test case are
required to cover all transitions ?

A.3
B.4
C.5
D.6
 2- Structure-Based Techniques

• Statement Testing and Coverage

• Decision (Branch)Testing and Coverage
• Other Structure-Based techniques
Statement Testing and Coverage

Increase Code Coverage … Increase Quality

 Statement Testing and Coverage

The % of executable statements that have been exercised.

Example 1
Given the following program fragment:

If x = 3
Print (“hello”)

What is the minimum number of test cases needed to achieve 100%

statement coverage?

A.1
B.2
C.3
D.4
Print sum (int a, int b) {
int result = a + b;
if (result > 0)
print (“red”, result)
else if (result < 0)
print (“blue”, result)
}
How many test cases are necessary to achieve 100 % statement coverage
A.1
B.4
C.3
D.2
Consider the following control flow chart:
You have run one test case: 1-2-3-4-5-6-7-8-9-10
What percentage of statement coverage have you achieved?

a.50 %
b.80 %
c.90 %
d.100 %
• Evaluate the following control flow diagram and determine the
statement coverage resulting from the execution of the following test
cases:

A-B-D-A-B
A-B-D-E-F

a.33 %
b.53 %
c.83 %
d.100 %
How is statement coverage determined?

a. Number of test decision points divided by the number of test cases

b. Number of decision outcomes tested divided by the total number of

executable statements

c. Number of possible test case outcomes divided by the total number of

function points

d. Number of executable statements tested divided by the total number

of executable statements
B) Decision(branch) Coverage Testing

Increase Code Coverage … Increase Quality

How to measure decision coverage ?
Example 1
 Example 2
Read A
Read B
IF A > 0 THEN
IF B = 0 THEN
Print “No values”
ELSE
Print B
IF A > 21 THEN
Print A
ENDIF
ENDIF
ENDIF

• Cyclomatic complexity: __4___

Minimum tests to achieve:
• Statement coverage: __2____
• Branch coverage: ___4__
 Example 3

Read A
Read B
IF A < 0 THEN
Print “A negative”
ELSE
Print “A positive”
ENDIF

IF B < 0 THEN
Print “B negative”
ELSE
Print “B positive”
ENDIF

• Cyclomatic complexity: ___3__

Minimum tests to achieve:
• Statement coverage: ___2___
• Branch coverage: __4___
 All decision outcomes

2 To 3
2 To 5
4 To 3
4 T0 5
5 To 8
5 To 6
7 To 6
7 To 8
8 To 9
8 To 10
decision outcomes covered by testcase
2 To 3
4 T0 5
5 To 6
7 To 8
8 To 9
The following statement refers to decision coverage: “When the code
contains only a single ‘if’ statement and no loops or CASE statements, any
single test case we run will result in 50% decision coverage.”
Which of the following sentences is correct?

A. The sentence is true. Any single test case provides 100% statement
coverage and therefore 50% decision coverage
B. The sentence is true. Any single test case would cause the outcome of
the “if” statement to be either true or false
C. The sentence is false. A single test case can only guarantee 25% decision
coverage in this case
D. The sentence is false. The statement is too broad. It may be correct or
not, depending on the tested software
Which TWO of the following statements about the relationship between
statement coverage and decision coverage are true?

A. Decision coverage is stronger than statement coverage.

B. Statement coverage is stronger than decision coverage.
C.100% statement coverage guarantees 100% decision coverage
D.100% decision coverage guarantees 100% statement coverage
E. Decision coverage can never reach 100%.
If you are testing a module of code, how do you determine the level of decision
coverage you have achieved?

A. By taking the number of decisions you have tested and dividing that by the
total number of executable statements in the module

B. By taking the number of decisions you have tested and dividing that by the
total number of decisions in the module

C. By taking the number of decisions you have tested and dividing that by the
total lines of code in the module

D. By taking the number of decision outcomes you have tested and dividing
that by the total number of decision outcomes in the module
If you have a section of code that has one simple IF statement, how many
tests will be needed to achieve 100% decision coverage?

A.1
B.2
C.5
D. Unknown with this information
 Hint

100% branch (Decision) coverage => 100% statement coverage

100% statement coverage does not imply 100% branch (Decision)

coverage
Multiple Conditions
3) Experience-Based Techniques
 3) Experience-Based Techniques
• The test cases are derived from the tester’s skill and intuition, and their
experience with similar applications and technologies.

• These techniques can be helpful in identifying tests that were not easily
identified by other more systematic techniques.

• Depending on the tester’s approach and experience, these techniques

may achieve different degrees of coverage and effectiveness.

• Coverage can be difficult to assess and may not be measurable with

these techniques.
A) Error Guessing Technique
Error Guessing Technique
Error guessing is a technique used to anticipate the occurrence of mistakes,
defects, and failures, based on the tester’s knowledge, including:

•How the application has worked in the past

A>> B>> C
A>>C
•What types of mistakes the developers tend to make

•Failures that have occurred in other applications

 Error Guessing Technique
• A methodical approach to the error guessing technique is to create a list of possible mistakes, defects, and
failures, and design tests that will expose those failures and the defects that caused them.
Login by phone number
1.
2.
3.
4.
5.
6.
0797021021
00797021021962797
Login by email
1.
2.
3.

• These mistake, defect, failure lists can be built based on experience, defect and failure data from common
knowledge about why software fails.
 B) Exploratory Testing Technique

• In exploratory testing, informal tests are designed, executed, logged, and evaluated
dynamically during test execution.

• The test results are used to learn more about the component or system, and to create
tests for the areas that may need more testing.

• Exploratory testing is sometimes conducted using session-based testing to structure the

activity.

• In session-based testing, exploratory testing is conducted within a defined time-box, and

the tester uses a test charter containing test objectives to guide the testing.
B) Exploratory Testing Technique
• Exploratory testing is most useful when there are few specifications
or significant time pressure on testing.
• NOT Random Testing
 C) Checklist-based Testing
• In checklist-based testing, testers design, implement, and execute tests to cover test conditions
found in a checklist.

• As part of analysis and review , testers create a new checklist or expand an existing checklist, but
testers may also use an existing checklist without modification.

• Such checklists can be built based on experience, knowledge about what is important for the user, or
an understanding of why and how software fails.

• Checklists can be created to support different test types, including functional and non-functional
testing.

• In the absence of detailed test cases, checklist-based testing can provide guidelines and a degree of
consistency.
Which Technique to choose ?
Why Complementary?
Which of the following situations is NOT suited for using exploratory
testing?

A. When there is time pressure, and/or the requirements are incomplete

or inapplicable

B. When the system is developed and tested incrementally.

C. When only new and inexperienced testers are available

D. When the main part of the application can be tested only at the
customer’s site.
Which of the following is a good reason to use experience-based testing?

A. You can find defects that might be missed by more formal techniques
B. You can test for defects that only experienced users would encounter
C. You can target the developer’s efforts to the areas that users will be
more likely to use
D. It is supported by strong tools and can be automated
If you are using error guessing to target your testing, which type of testing
are you doing?

A. Specification-based
B. Structure-based
C. Experience-based
D. Reference-based
What is error guessing?

A. A testing technique used to guess where a developer is likely to have

made a mistake

B. A technique used for assessing defect metrics

C. A development technique to verify that all error paths have been coded

D. A planning technique used to anticipate likely schedule variances due to

faults
When exploratory testing is conducted using time-boxing and test charters,
what is it called?

A. Schedule-based testing
B. Session-based testing
C. Risk-based testing
D. Formal chartering