ISTQB Certified Tester Foundation Level

• Module 4 of 6: Test Design Techniques

February, 2017
Study Sessions
• These study packs are intended as sessions directly from the chapters in the
syllabus

• 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
Covered in this session...

• The test development process

• Categories of test design techniques
• Specification-based or black box techniques
• Structure-based or white box techniques
• Experienced-based techniques
• Choosing test techniques

3
Test Development Process
 Test Development Process
The process can be Remember
Remember Principle
Principle 6
6 –– Testing
Testing is
is context
context
• Very informal with little or no dependent
dependent
documentation E.g. May test differently on web
• Very formal with lots of info page vs. Safety critical
breaking system
documentation

Depends on the context for testing

• Organisation and the type of software
• Maturity of testing and development processes
• Time constraints and the people involved

5
How would you test software without requirements?

User
Manual Heuristics

What we
Experience
d User know of
software
Software

6
How would you test software with 1,000 documents?

Business
Business Technical
Technical Architecture
Architecture
Use
Use Cases
Cases Process
Process Flows
Flows Transactions
Transactions
Requirements
Requirements Requirements
Requirements Diagrams
Diagrams

7
Test Design and the Fundamental Test Process
Planning
Planning and
and
Control
Control

2. Identify test 3. Design test

Analysis
Analysis and
and 1. Analyse test
conditions (using cases and test
Design basis
Design techniques) data

4. Develop test 5. Develop test

Implementation
Implementation procedure execution
and
and Execution
Execution specification schedule

Evaluate
Evaluate Exit
Exit
Criteria and
Criteria and
Reporting
Reporting

Test
Test Closure
Closure

8
Test Development Process

1. Analyse Test Basis and Prioritise

2. Identify Test Conditions and Prioritise

3. Design Test Cases and Prioritise

4. Develop Test Procedure Specification and Prioritise

5. Develop Test Execution Schedule and Prioritise

9
Step 1: Analyse the Test Basis

• Select the Test Basis

• Study and evaluate testability
• E.g. Business Requirements Specification,
Use Cases, etc…

• Prioritise
• Which test basis to use for testing first?

10
Step 2: Identify Test Conditions

• Use the chosen test design technique

• The approach may be specified in the Test Strategy

• List the test conditions

• Prioritise
• Ensure the most important test conditions are identified

• Traceability
• From test conditions back to specifications and requirements
• Enables impact analysis when things change
• Helps to determine requirements coverage in both planning and execution

11
What is a Test Condition?

• An item or event that could be verified by one or more test cases.

• Eg.
• Function
• Transaction
• Feature
• Quality characteristic
• Structural element

• Testers usually brainstorm all the possible test conditions for the requirement/feature that they
are testing
• Then we pick the most appropriate test conditions and build into test cases

12
 Examples of Test Conditions
Employee Record

Add Delete Edit Save

• Screen for an Employee Record First Name:

Last Name:
• Functions: Add, Delete, Modify… Date Joined:
• Features: Role based security – who can delete?
Role:
• Fields: Date Joined (Date formats)
Role (from a drop down list)
• Quality Characteristics: Concurrent users, Usability,
Transaction time to save changes?
• Structural Elements: Page navigation, Variables in code (white box), Coverage?

Test conditions are also referred to as the

Test Design Specification
(IEEE 829 - Standard for Software
Software Test Documentation)

13
Step 3: Identify Test Cases

• Select the test conditions to be tested

• Design test case

• Test Case Specification

• A document specifying a set of test cases
• Objective Specified in the IEEE – 829:
Standard for Software Test
• Inputs Documentation
• Test actions (steps)
• Expected results
• Execution preconditions
Test cases are also referred to as the
Test Case Specification

14
What is a Test Case?

• A set of input values

• E.g. Debit transaction $205.70 from Account for Jane Smith
• With Preconditions
• E.g. Account for customer Jane Smith with zero balance
• Expected results and post conditions
• E.g. Message to user “Insufficient funds”, Account for Jane Smith is not debited.
• For a particular objective or test condition
• E.g. Test condition “Can’t debit a zero balance account”
• To verify compliance with a specific requirement or exercise a particular program path
• E.g. Requirement “When a customer attempts to debit an account with insufficient funds an
error message is displayed and the account is not debited.

15
Step 4: Develop the Test Procedure Specification

• During test implementation

• Test cases are developed, implemented, prioritised and organised into the test procedure specification

Test
• Specifies sequence of action Procedure
1
• Manual test script
• Automated test procedure when script
1.
executed by a tool 2.
3.
4.
5.
• Prioritise Test Procedure Specifications
• Want to execute the most important ones first!

• Test Procedure Specification is also in IEEE 829

16
Step 5: Develop the Test Execution Schedule

• Order of test procedures and possibly automated scripts to execute

• By whom
• Take into account Test
Procedure
• Regression tests 1
• Prioritisation
• Technical and logical dependencies 1.
2.
• (Eg. Must execute Test Case A, 3.
4.
before Test Case B to put account into arrears 5.

that is needed for Test Case B)

• Example: the “Test Lab” in HP Quality Center

with test cases in set order assigned to
different testers
17
Categories of Test Design
Techniques
 19

Other
Other structure-based
structure-based
Techniques
White-box

techniques
techniques
Structure-based

Decision
Decision testing
testing and
and
coverage
coverage
Statement
Statement testing
testing and
and
coverage
coverage
Exploratory
Exploratory testing
testing approach
approach
Experienced-

Fault
Fault attack
attack
based
Black-box Techniques
Categories of Test Design Techniques

Error
Error guessing
guessing
Use
Use case
case testing
testing
Specification-based

State
State transition
transition testing
testing
Decision
Decision table
table testing
testing
Boundary
Boundary value
value analysis
analysis
Equivalence
Equivalence partitioning
partitioning
Why use test design techniques?

• Consistency
• “Best” practice
• Systematic
• Testers may have different levels of experience
• Save time
• Impossible to test all permutations, therefore we have to choose what we will test

Remember
Remember Principle
Principle 2
2 –– Exhaustive
Exhaustive testing
testing is
is
impossible
impossible

So, we need an intelligent way of devising what to test!

20
Specification-based or black-box techniques

• Systematically derive tests from formal or informal models (descriptions) used for the specification
of the software
• Analysis of the test basis
• Based on documentation or what we know
• “what” the system should do
• Without reference to its internal structure

21
Structure-based or white-box techniques

• Derive test cases from

• Analysis of the structure of the component or system
• Code, detailed design and menu structure
• “how” the system is constructed

• The extent of test coverage can be measured (by a tool) for existing test cases and further test
cases can be derived to increase coverage

00
22
Experienced-based techniques

• Utilising the knowledge and experience of people to derive test cases

• Knowledge of testers, developers, users, stakeholders, etc.

• About the software, its usage and its environment
• Knowledge about likely defects and their distribution

• Useful when augmenting with systematic techniques

• Can give varying results of effectiveness depending on the testers’ experience

23
 Specification-based (Black-box) Techniques

Equivalence Partitioning
Equivalence Partitioning

• Inputs are divided into groups that are expected to behave similar

• Can be done for valid and invalid partitions

• Can also be identified for

• Outputs
• Internal values and interface parameters
• Time-related values

• Can be done at all levels/phases of testing

Partitions are also called Classes

25
Equivalence Partitioning

Activity
• Let’s derive the equivalence classes for an application that lets you apply for your driver’s license

• In Victoria, Australia you must be at least 18 yrs. old to apply for your probationary license
• Let’s say theoretically you must stop driving when you are 90 yrs. old

Invalid Valid Invalid

17 18 89 90
Others?
Others?
Non-
Non-
integer
integer
26
 Specification-based (Black-box) Techniques

Boundary Value Analysis

Boundary Value Analysis

• Behaviour at the edge of a partition is more likely to be incorrect

• Defects lurk on boundaries!

• Can be done at all levels/phases of testing

• Detailed specifications are helpful
• Good at finding defects
• Good at finding rounding errors

• Can be used on input screens as well as ranges

– e.g. time out, transaction speed, table size

28
Boundary Value Analysis
Back to our activity…
• In Victoria you must be at least 18 yrs. old to apply for your probationary license
• Let’s say theoretically you must stop driving when you are 90 yrs Old

Invalid Valid Invalid

17 18 89 90

Question: What values would you choose to test the boundaries?

Answer: 17,18 and 89, 90
• There is a variant called 3-BVA
o On the boundary and either side = 17,18, 19 and 88, 89, 90

29
Why do both EP and BVA?

• Use both EP and BVA = Stronger, more thorough testing

• If you test only EP you could miss rounding errors

• But, could be useful for Acceptance Testing with minimal tests

• If you test only BVA and you find an error, you have to test more options anyway – is just the
boundary wrong or the whole partition?
• But could be useful if there are time pressures and you are looking to find defects first, so test
boundaries only.
• If you do boundaries only, you have covered all the partitions as well.
• Boundary testing requires a lot more tests and may be expensive to set up.

30
Question: EP

• An airline offers pricing as follows; infants < 2 yrs. travel free, children aged between 2-11 yrs. at
75% of adult fare and adults at full price.

• Which of the following are age values from different VALID partitions for airfare pricing?
a) 0, 2, 10
b) -1, 1, 3
c) 1, 7, 45
d) 2, 9, 12

31
Question: 2-BVA

• An electricity company charges usage <1000 kW at $0.13 per kW, between 1000 and 5000 kW
inclusive at $0.22 per kW and >5001 kW at $0.28 per kW

• Using 2-BVA what usage inputs should be tested?

a) 1000, 1001, 5000, 5001
b) 999, 1000, 4999, 5000
c) 999, 1000, 5000, 5001
d) 1000, 1001, 4999, 5000

32
Question: 3-BVA

• A bank’s saving account earns an additional 2% interest when the balance of the account is
greater than $10,000

• Using 3-BVA what account balance inputs should be tested?

a) 10,000, 10,001, 10,002

b) 9,999, 10,000, 10,001
c) 9,998, 9,999, 10,000
d) 9,999, 10,001, 10,002

33
Specification-based (Black-box) Techniques

Decision Tables
Decision Table Testing

• Decision tables are great for requirements with logical conditions

• Like complex business rules

• The strength of decision tables is that it creates combinations of conditions, inputs situations and
events that might be missed
• The top part of the table contains combinations of input conditions
• The bottom part contains the resultant actions as True or False (Boolean)
• Each column can then be considered as a test case of a business rule
• Coverage standard could be at least one test for each column to trigger all combinations of
conditions.
Exam Tip: Decision Table Testing is good for
testing business rules or combinations

35
Example: Shipping an online order

• Online order system rules

• There must be items in the cart
• Shipping address must not be a PO. Box
• Orders can be placed from accounts with a credit balance

Conditions
• Cart has something in it
• Shipping address is a PO box
• Account balance is in credit

Actions
• Item is shipped
• Account is debited
36
Construct the decision table

Spec
Spec doesn’t
doesn’t
say
say
Not
Not feasible,
feasible, so
so Same
Same resulting
resulting
actions… Each
Each column
column is
is aa
remove?
remove? actions… do
do
conditions matter? test
test case
case
conditions matter?
37
Rationalise the decision table

Be careful with assumptions made when rationalising

You may remove valid or important combinations

38
Question: Decision table

Test case A: 2 yr customer, pays late, bad credit history

Test case B: 6 month customer, pays on time, bad credit history
a) A: $5 credit, no letter B: Nothing on next bill, no letter sent
b) A: nothing on next bill, no letter B: Nothing on next bill, letter sent
c) A: $15 debit on next bill, letter sent B: $10 credit on next bill, no letter sent
d) A: $15 debit on next bill, letter sent B: Nothing on next bill, no letter sent

39
Specification-based (Black-box) Techniques

State Transition Testing

State Transition Testing
A system may exhibit a different response depending on current conditions or
previous history. A state transition diagram allows a tester to view the software in
terms of its states, transitions between states, inputs or events that trigger state
changes (transitions) and resulting actions.

Example: a vending machine

money inserted
ask for selection invalid selection
beep

wait for wait for

money cancel selection
return money
valid selection
Give item
insufficient funds
ask for money
41
State Transition Testing
money inserted
invalid selection
ask for selection
beep

wait for wait for

money cancel selection
return money
valid selection
Give item
insufficient funds
ask for money

Model shows:
• states the software can occupy (the circles)
• transitions between the states (the lines)
• events that cause the transitions
• actions that result from the transition

42
State Transition Testing

• Different events may trigger a specific action and transition to another state of the system.

• Tests can be designed to cover every state, a typical sequence, every transition or to test invalid
transitions

Tip: To cover every state – cover the circles

To cover every transition – cover every line

State transition testing may be used in technical automation, modelling

a business object or screen dialogue flows (e.g. navigation of web
pages)

43
State Transition Testing – Vending Machine Example

1.Which sequence would be testing a typical transaction flow?

2.What is the minimum number of tests required to test every state?
Answer: 1
Cross every circle
3.How many tests are required for testing every transition?
Answer: 3
Cover every line.
This is also know as Chow’s 0-switch Coverage
44
State Transition Diagram Example: Account Login
Cancel

Cancel S6
S1 Suspend
start Password Acct
invalid
S2 S3 S4 Password
Enter Password
1st 2nd 3rd invalid
Username invalid
attempt attempt attempt

Password Password Password

valid valid valid
S5
Typical transaction Access
account
Every state
Minimum nbr of tests for state coverage =
Every transition Minimum nbr of tests for Chow’s 0 switch coverage =

45
State Transition Table

Use the state table to identify invalid

(or unspecified / specification doesn’t say) transitions
Question: Which of the following is not a valid transition?
a) Password Valid from S3
b) Cancel from S4
c) Enter Username from S1
d) Password Invalid from S5
46
Practice Question Cancel

Cancel Password S6
S1
S2 S3 invalid S4 Suspend
Start
1st 2nd 3rd Acct
Password
Enter attempt attempt attempt
invalid Password
Username Password
Password invalid
Password valid
valid
valid S5
Access
Acct

Which two tests will cover all states?

a) S1 – S2 – S3 – S4 – S5 and S1 – S4 – S6
b) S1 – S2 – S3 – S4 – S5 and S1 – S2 - S3 – S4 – S6
c) S1 – S2 – S3 – S4 – S5 and S1 – S2 - S1 – S4 – S6
d) S1 – S2 – S3 – S4 – S5 and S4 – S6

47
Specification-based (Black-box) Techniques

Use Case Testing

Use Case Testing

• Use cases describe process flows through a system

• Including mainstream (most likely) and alternate (exception) flows
• Interactions between actors (users and the system) to produce a result
• Each use case has pre-conditions and post-conditions

Use cases are good for

• designing acceptance tests
• Involving customers
• Finding defects in integration between components

49
Use Case – Table Format

50
Use Case – Table Format Example

51
Use Case – Diagram Format

Source: http://argouml-stats.tigris.org/nonav/documentation/manual-0.22/ch04s03.html

Actors: Bank Engineer, Customer, Loan Bank Official and Central Computer
Further Use Cases e.g. for Withdraw Cash for more detail on this transaction
52
 Structure-based (White-box) Techniques

Statement Testing & Coverage

Structure-based Testing

• Based on an identified structure

• Component level: code (statement, branches, decisions)
• Integration level: call tree diagram
• System level: menu structure, business process or web page navigation

Tip: Often see questions related to coverage when talking

about structure-based testing as we can measure how many
items (lines of code, components, classes, menu items) are
exercised by our tests.

54
Statement Testing and Coverage

Test Coverage
• Here we devise test suites with information on how many statements they
exercise to achieve a coverage target

• Usually involves a tool that measures statement coverage during test execution

• Usually for safety critical testing to ensure every statement is tested

55
How to draw a control flow diagram

• A control flow diagram helps show the logic in a program

• Read pseudo code for a program

• Draw from top to bottom as you would read it
• The indentation in the pseudo code should help you read and understand the logic of the program

• Statements are boxes

IF
• Decisions (e.g. IF) are represented by diamonds

• Be consistent
• Eg. Always draw to the right for “true” decisions

56
Statement Testing and Coverage: Example 1
Qty
Question: How many statements are
exercised if we set the input value of
1. Read Qty “Qty” to 10?

IF
True Answer = 4 out of 5
2. IF Qty > 50 >50 statements
Statement Coverage = 80%
Else
X=Qty
*0.8

3. Qty = Qty * 0.8

End If

4. End If

Print X
5. Print Qty

57
Statement Testing and Coverage: Example 2
1. Read Qty Qty Question: How many statements
are exercised if we set the input
value of “Qty” to 100?
2. IF Qty > 50
True
IF Answer = 5 out of 5 statements
>50 Statement Coverage = 100%!!!
Else
X=Qty
3. Qty = Qty * 0.8 *0.8

End If
4. End If

Print X
5. Print Qty
But wait... Are we missing something?

Tip: 100% Statement Coverage means cover all of the boxes!

58
 Structure-based (White-box) Techniques

Decision Testing & Coverage

Decision Testing and Coverage

• Decision coverage is the assessment of the percentage of decision outcomes exercised (e.g. the
True and False options of the IF statement)

• Related to branch testing and control flow testing

• Decision coverage is always stronger than statement coverage

• 100% decision coverage guarantees 100% statement coverage, but not vice versa

• Again, Decision Coverage is usually measured by a tool

60
Decision Testing and Coverage
1. Read Qty Qty Question 1: How many tests
are required to achieve 100%
statement coverage?
True
Answer = 1 Test
2. IF Qty > 50 IF e.g. Value Qty = 100
>50

Else Question 2: How many tests

3. Qty = Qty * 0.8 X=Qty are required to achieve 100%
*0.8
decision coverage?
4. End If Answer = 2 Tests,
End If e.g. Values 1 and 100

Tip:
Tip: 100%
100% Decision
Decision Coverage
Coverage means
means cover
cover all
all of
of
5. Print Qty the lines!
the lines!
Print X

Tip:
Tip: 100%
100% Decision
Decision Coverage
Coverage is
is always
always == or
or >> nbr
nbr of
of tests
tests needed
needed for
for 100%
100% Statement
Statement coverage.
coverage. Never
Never less
less
than!
than!
61
Decision Testing: IF with Else Question 1: How many tests are
Qty
required to achieve 100%
statement coverage?
1. Read Qty IF
>50
True Answer = 2 Tests,
2. IF Qty > 50 e.g. values 1 and 100
Else X=Qty
3. Qty = Qty * 0.8 *0.8

Question 2: How many tests

4. Else X=Qty are required to achieve
* 1.5
100% decision coverage?
5. Qty = Qty * 1. 5
End If Answer = 2 Tests
6. End If
Print X
7. Print Qty

62
Decision Testing: Nested IF Statements

1. Read Qty
2. IF Qty > 50 Have a go at drawing the
3. X = Qty * 0.8 control flow diagram in
4. Else your notes 
5. IF Qty < 0
6. Print “Error”
7. Else
8. X = Qty * 2
9. End If
10. End If
11. Print X

63
Decision Testing: Nested IF Statements
Qty Question 1: How many tests
are required to achieve 100%
IF
True statement coverage?
1. Read Qty >50
2. IF Qty > 50 Answer = 3 Tests,
Else
e.g. Values 100, -1
3. X = Qty * 0.8 and 25
True
IF Print X=Qty
4. Else “Error” *0.8
<0
5. IF Qty < 0 Else
6. Print “Error” X=Qty Question 2: How many
7. Else *2
tests are required to
8. X = Qty * 2 End If achieve 100% decision
9. End If coverage?
10. End If End If Answer = 3
11. Print X
Print X

64
Decision Testing: WHILE LOOP
Read
Question 1: How many tests
are required to achieve 100%
1. Read Nbr_Exams statement coverage?
WHILE

False Answer = 1 Test

2. WHILE more exams DO True
Mark

3. Mark answers Question 2: How many tests

Collate
are required to achieve 100%
4. Collate total marks decision coverage?
End
WHILE
Answer = 1 Test
5. END WHILE
Print

6. Print “No more to mark”

65
WHILE LOOP with nested IF Statement
Read Question 1: Minimum tests
1. Read Number of Exams
to achieve 100% statement
2. WHILE more exams DO
coverage?
WHILE
False
Answer = 1 Test
3. Mark answers True

4. Collate total marks Mark

5. IF Score < 65 Question 2: Minimum
6. Fail = Fail + 1 Collate tests to achieve 100%
decision coverage?
7. End If
IF < 65 Fail Answer = 1 Test
8. END WHILE
End If
9. Print “No more to mark”
End
WHILE
Tip: Anything within a WHILE LOOP can
Print be covered with only 1 test!
66
WHILE LOOP and more IF statements Read
1. Read Number of Exams
2. WHILE more exams DO WHILE
3. Mark answers
Have a go at drawing the
4. Collate total marks Mark & control flow diagram
Collate
5. IF Score < 65
6. Fail = Fail + 1 IF < 65 Fail

7. End IF
End If
Question 1: Minimum tests
8. END WHILE to achieve 100%
End
9. Class Result = Fail/Exams WHILE statement coverage?
10. IF Fail < 30% Class Answer = 2
Result
11. Print “Smart Class”
Question 2: Minimum tests
12. ELSE IF < 30 Smart to achieve 100% decision
13. Print “Poor Trainer” coverage?
14. END IF Poor
Trainer
Answer = 2
END IF
67
Other Structure-based Techniques

• There are even stronger coverage levels than decision coverage

• E.g. LCSAJ, combination coverage

• We have been looking at detailed low-level coverage, but coverage can also be
applied to higher-levels like…
• System Testing: % of menu items covered by test cases
• Integration Testing: % components exercised

68
 Experienced-based techniques

Error Guess & Exploratory

Testing
Experienced-based techniques

• Utilising tester’s skill, intuition and experience with similar applications or technologies

• Useful when complementing systematic techniques and when special tests not easily captured by
formal techniques

• Can yield varying degrees of effectiveness

• Error Guessing
• Anticipate defects based on experience
• Common knowledge of system, data and why system fails
• Or develop a list of possible errors and design tests to systemically attack these errors: this
approach is called Fault Attack

70
Exploratory Testing

• Concurrent test design, execution, logging and learning how the system behaves

• Tester builds a “mental model” of the system while they test it

• Useful approach when

• there are few or inadequate specifications
• severe time pressure
• complementing more formal testing
• can be used to help ensure the most
serious defects are found

71
Exploratory Testing

• Is an approach not a technique

• Also known as Session-Based Test Management (SBTM)

• Based on a Test Charter

• A specified mission in a set time.
• E.g. Look for bugs creating forms using IE7 for 60 minutes
• Include objectives and time box the session
• Tester records notes on how the session went including obstacles encountered and suggestions
on where to focus future sessions

• Collate metrics on Exploratory Testing to show effectiveness

• E.g. Hours spent and number of defects found by severity

72
Choosing Techniques
Choosing Test Techniques

• The choice depends on a number of factors…

• Type of system
• Regulatory or legal standards
• Customer or contract requirements
• Level of risk
• Test objectives
• Documentation available
• Knowledge of testers
• Time and budget
• Software Development Lifecycle Model
• Previous experience of the type of defects found

74
Question 1: Which techniques would you use?
 Scenario Techniques
• Banking application
• Previous problems with  Equivalence Partitioning
rounding errors  Boundary Value Analysis
• Lots of combinations
 State transition testing
of possible factors
• Good documentation  Decision tables
• Experienced testers  Use case testing
• Time constraints
 Statement testing
 Decision testing
 Error guessing
 Exploratory testing

75
Question 2: Which techniques would you use?
 Scenario Techniques
• Web site
• Little documentation  Equivalence Partitioning
• Previous problems with navigation  Boundary Value Analysis
• Experienced testers
 State transition testing
• Time constraints
 Decision tables
 Use case testing
 Statement testing
 Decision testing
 Error guessing
 Exploratory testing

76
Question 3: Which techniques would you use?
 Scenario Techniques
• Train automatic braking system
• Lots of documentation  Equivalence Partitioning
• Previous problems with  Boundary Value Analysis
untested combinations
 State transition testing
• Safety standards require
decision coverage  Decision tables
• High risk  Use case testing
• Experienced testers
 Statement testing
 Decision testing
 Error guessing
 Exploratory testing

77
 End of Module 4

QUESTIONS
End of Module Learning Check

1. Which category of test techniques does Decision Testing belong to?

A. Specification-based
B. Experience-based
C. Structure-based
D. Black-box

2. Which of the following is a false characteristic of “Good” testing?

A. Is always very thorough
B. Test early
C. Focus on objectives
D. Testing activity for every development activity

79
ISTQB Practice Exam Question 1

One of the coverage goals for the project is 100% decision coverage. The following 3 tests have been
executed for the control flow graph below. A

• Test A covers path: A, B, D, F, G

B C
• Test B covers path: A, C, F, G
• Test C covers path: A, C, F, C, F, C, F, G
D
Which of the following statements related to the
decision coverage goal is correct?
A. Decision D has not been tested completely. E F
B. 100% decision coverage has been achieved.
C. Decision E has not been tested completely.
G
D. Decision F not been tested completely.

80
ISTQB Practice Exam Question 2
A bank application determines the creditworthiness of customers.
The application uses a set of rules to determine the upper limit of the
credit amount. Which of the following black-box test design
techniques is best for testing the application?

A. Decision table testing

B. State transition testing
C. Use case testing
D. Equivalence partitioning

81