Chapter 4 - Test Analysis & Design Techniques V4.0

Test Analysis & Design
1 Fundamentals
2 Testing
in Lifecycle
4 Analysis
& Design
3 Static testing
5 Test
Management
6 Test Tools
ISTQB Foundation
Chapter - 4

TM
© 2023. All Rights Reserved
Content
4.1 Test Techniques Overview
4.2 Black-box Test Techniques
4.3 White-box Test Techniques
4.4 Experience-based Test Techniques
4.5. Collaboration-based Test Approaches

TM
Test Techniques at a context
 Test techniques support the tester in test analysis (what to test) and in test design (how to test).
 Test techniques help to develop a relatively small, but sufficient, set of test cases in a systematic way.
 Test techniques also help the tester to define test conditions, identify coverage items, and identify test data during the
test analysis and design.
Test Techniques Overview

TM
 Black-box test techniques (also known as specification-based techniques) are based on an analysis of the
specified behavior of the test object without reference to its internal structure.
 Therefore, the test cases are independent of how the software is implemented.
 Consequently, if the implementation changes, but the required behavior stays the same, then the test cases are still
useful.
 Techniques under this category
 Equivalence Partition
 Boundary Value Analysis
 State Transition Testing
 Decision Table Testing

TM
 White-box test techniques (also known as structure-based techniques) are based on an analysis of the test object’s
internal structure and processing.
 As the test cases are dependent on how the software is designed, they can only be created after the design or
implementation of the test object.
 Statement Testing and Coverage
 Branch Testing and Coverage

TM
 Experience-based test techniques effectively use the knowledge and experience of testers for the design and
implementation of test cases.
 The effectiveness of these techniques depends heavily on the tester’s skills.
 Experience-based test techniques can detect defects that may be missed using the black-box and white-box test
techniques.
 Hence, experience-based test techniques are complementary to the black-box and white-box test techniques.
 Error Guessing
 Exploratory Testing
 Checklist Based Testing

TM
 It divides inputs into ranges(partition or class) where all the elements of a particular range are expected to
behave same.
 As per EP we take just 1 test case from each range.
Equivalence Partition

TM
 An integer field shall contain values between and including 1 to 15. By applying Equivalence Partition what is the
minimum number of test cases required for maximum coverage?
A. 2
B. 3
C. 1
D. 4
Invalid Valid Invalid
< 1 1 - 15 16 ≤

TM
 An integer field shall contain values between and including 1 to 15. By applying EP which of the following is a valid
collection of equivalence classes for the given scenario.
A. Less than 1, 1 through 15, more than 15
B. Negative numbers, 1 through 15, above 15
C. Less than 1, 1 through 14, more than 15
D. Less than 0, 1 through 14, 15 and more 3
< 1 1 - 15 16 ≤

TM
 In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10% The next £28000 is taxed at 22% Any
further amount is taxed at 40% Which of these groups of numbers would fall into the same equivalence class?
A. £4800; £14000; £28000
B. £5200; £5500; £28000
C. £28001; £32000; £35000
D. £5800; £28000; £32000
Valid
5501 - 33500
Valid
33501≤
Valid
4001 - 5500
Valid
1 - 4000

TM
 You are testing a simplified apartment search form which has only two search criteria:
 floor (with three possible options: ground floor; first floor; second or higher floor)
 garden type (with three possible options: no garden; small garden; large garden)
Only apartments on the ground floor have gardens. The form has a built-in validation mechanism that will not allow you to
use the search criteria which violate this rule.
Each test has two input values: floor and garden type. You want to apply equivalence partitioning (EP) to cover each floor
and each garden type in your tests.
What is the minimal number of test cases to achieve 100% EP coverage?
A. 3
B. 4
C. 5
D. 6
Floor Garden Type
Test 1 Ground Floor Small
Test 2 Ground Floor Large
Test 3 First Floor No Garden
Test 4 Second or Higher Floor No Garden

TM
 You are testing a flight booking application of Arline ABC. Below are the constraints in order to book a flight ticket
 Only staff of ABC Airline can book a flight
 A flight can be booked only on a weekday (Monday to Friday)
 A flight can be booked only between 9am to 5pm
Each test contains inputs from all 3 constraints to reduce the number of test cases. What is the minimal number of test
cases to achieve 100% EP coverage?
A. 3
B. 4
C. 5
D. 6
User Type Day Time
Test 1 Staff Weekday (ANY) 11am
Test 2 Staff Weekday (ANY) 7pm
Test 3 Staff Weekend (ANY) 1pm
Test 4 Non-Staff Any Day of the week Any Time of the day

TM
 BVA tests on the boundaries the defect can lie near the boundaries as well.
 The values in valid range are called as valid boundary values whereas the values from invalid range are called invalid
boundary values.
 Boundary values for 2-Point analysis are calculated as LB, LB-1, RB, RB+1 where LB and RB are the LEFT and RIGHT
boundaries given in the scenario.
 Boundary values for 3-Point analysis are calculated as LB, LB+1, LB-1, & RB, RB-1, RB+1 where LB and RB are the LEFT
and RIGHT boundaries given in the scenario.
Boundary Value Analysis
LB RB
LB-1 RB+1
LB RB
LB-1 RB+1
LB+1 RB-1

TM
 A text field in an application accepts inputs as the age of the user. Here, the values allowed to be accepted by the field is
between 18 to 30 years, inclusive of both the values. By applying 3-Point Boundary value analysis what is the minimum
number of test cases required for maximum coverage.
A. 2
B. 6
C. 1
D. 4
≤17 18 - 30 31≤

TM
 Minimum quantity to place the order is 5. To get additional 10% off, you should buy 100 or more quantity. Based on
Boundary value analysis which of the given option consist of valid collection of boundary values using 2 Point Analysis.
A. 3, 4, 99, 100
B. 4, 5, 100, 101
C. 4. 5. 99, 100
D. 3, 4, 99, 100
No Order
Order Without
Discount
≤4 5 - 99 100≤
Order Without
10% Discount

TM
 A text field in an application accepts inputs as the age of the user. Here, the values allowed to be accepted by the field is
between 18 to 30 years, inclusive of both the values. By applying EP and 2 Point BVA which of the given option consist
of valid boundary values and valid equivalence value.
A. 17, 18, 20
B. 18, 30, 25
C. 18, 30, 31
D. 19, 20, 31
≤17 18 - 30 31≤
2P BVA
EP

TM
 Decision Table captures system requirements that contain logical conditions.
 The specification are analyzed, and conditions and actions of the system are identified in a tabular form.
 The input conditions and actions are most often stated in a way that they must be true or false.
 The number of combination will be 2N
 Where N = Number of Conditions
Decision Table Testing
Test Case 1 Test Case 2 Test Case 3 Test Case 4
Conditions
Condition 1 True True False False
Condition 2 True False True False
Actions
Action X X X X

TM
 What is the expected result for each of the following test cases?
 User X - Citibank card member, holding a Silver room
 User Y - Non Citibank-member, holding a Platinum room
A. X – Don’t offer any upgrade, Y – Don’t offer any upgrade.
B. X – Don’t offer any upgrade, Y – Offer upgrade to Gold.
C. X – Offer upgrade to Silver, Y – Offer upgrade to Silver.
D. X – Offer upgrade to Gold, Y – Don’t offer any upgrade.

TM
 Given the following decision table: Which of the following test cases and expected results is VALID?
A. 23 year old in insurance class A Premium is 90 and excess is 2,500.
B. 51 year old in insurance class C Premium is 100 and excess is 500.
C. 31 year old in insurance class B Premium is 70 and excess is 2,500.
D. 43 year old in insurance class C Premium is 100 and excess is 1,000.

TM
 State transition testing exhibits the various states of scenario/system and only possible transition between them.
 The representation is called as State Transition Diagram(STD).
 A STD shows all Valid Transitions Only.
 A STD consist of pair of transition between 2 states.
 If the pair is missing between 2 states then the missing transition/s is/are called as Invalid Transitions.
State Transition Testing
S1 S2 S3
A
D C
B

TM
For Example -
 State transition testing and State transition diagram of Water
ICE WATER VAPOUR
A
D C
B
Test Case ID TC01 TC02 TC03 TC04
Starting State ICE WATER WATER VAPOUR
Transition A D B C
Final State WATER ICE VAPOUR WATER

TM
 Based on the given state transition diagram of a switch. Which of the following test case is Invalid?
A. OFF to ON
B. ON to OFF
C. FAULT to ON
D. ON to FAULT
ON
OFF
FAULT
S1
S2
S3

TM
 Given the following state transition diagram, Which of the test cases below will cover the following series of state
transitions?
S1 SO S1 S2 SO
A. D, A, B, C.
B. A, B, C, D.
C. D, A, B.
D. A, B, C.

TM
 Because of their popularity and simplicity, this section focuses on two code-related white-box test techniques:
 Statement testing
 Branch testing
 There are more rigorous techniques that are used in some safety-critical, mission-critical, or high-integrity
environments to achieve more thorough code coverage.
 Statement Testing is the technique to derive the minimum number of tests to measure the statements in a fragment of
code whereas Statement Coverage is a metric to measure the coverage achieved by these tests.
 Branch Testing is the technique to derive the minimum number of tests to measure the branches in a fragment of code
whereas Branch Coverage is a metric to measure the coverage achieved by these tests.
 Decision Testing is stronger than Statement Testing.
 100% Decision Coverage guarantees 100% Statement Coverage but not vice versa.
Statement Testing

TM
Read A
Read B
If A>B then
Print “A is Bigger”
Else
Print “B is Bigger”
End If
Statement Testing
True
False
?
Start
End
Branch
Statement
A,B
A>B
A
B
End If

TM
Read A
Read B
If A>B then
Else
End If
A Path is the executable path which reaches
the end of the code starting from the start point.
Min no. of paths required for covering all the nodes.
Statement Testing
True
False
?
Start
End
2
1
A,B
A>B
A
B
End If

TM
Read A
IF A > 0 THEN
IF A = 21 THEN
Print “Key”
ENDIF
ENDIF
Statement Testing
Print
Yes
A=21
Yes
No
End
A>0
No
Read
T
F
T
F

TM
 Because of their popularity and simplicity, this section focuses on two code-related white-box test techniques:
 Statement testing
 Branch testing
 There are more rigorous techniques that are used in some safety-critical, mission-critical, or high-integrity
environments to achieve more thorough code coverage.
 Statement Testing is the technique to derive the minimum number of tests to measure the statements in a fragment of
code whereas Statement Coverage is a metric to measure the coverage achieved by these tests.
 Branch Testing is the technique to derive the minimum number of tests to measure the branches in a fragment of code
whereas Branch Coverage is a metric to measure the coverage achieved by these tests.
 Branch Testing is stronger than Statement Testing.
 100% Branch Coverage guarantees 100% Statement Coverage but not vice versa.
Branch Testing

TM
Read A
Read B
If A>B then
Else
End If
Branch Testing
True
False
?
Start
End
Branch
Statement
A,B
A>B
A
B
End If

TM
Read A
Read B
If A>B then
Else
End If
A Path is the executable path which reaches
the end of the code starting from the start point.
Min no. of paths required for covering all the nodes.
Branch Testing
True
False
?
Start
End
2
1
A,B
A>B
A
B
End If

TM
Read A
IF A > 0 THEN
IF A = 21 THEN
Print “Key”
ENDIF
ENDIF
Branch Testing
Print
Yes
A=21
Yes
No
End
A>0
No
Read
T
F
T
F

TM
For the given flowchart, following paths/test cases have been
executed. What decision coverage is achieved?
Test 1 – A,B,C
Test 2 – A,B,D,F,H
A. 50%
B. 63%
C. 75%
D. 100%
Branch Testing
D
B
A
C
F
E
G
H
Branch Coverage=
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐵𝑟𝑎𝑛𝑐ℎ𝑒𝑠 𝐸𝑥𝑒𝑐𝑢𝑡𝑒𝑑 𝑏𝑦 𝑡ℎ𝑒 𝑇𝑒𝑠𝑡
𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐵𝑟𝑎𝑛𝑐ℎ𝑒𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑐𝑜𝑑𝑒
𝑥 100

TM
For the given flowchart, following paths/test cases have been
executed. What Statement coverage is achieved?
Test 1 – A,B,C
Test 2 – A,B,D,F,H
A. 50%
B. 75%
C. 90%
D. 100%
Branch Testing
D
B
A
C
F
E
G
H
Statement Coverage=
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑆𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡𝑠 𝐸𝑥𝑒𝑐𝑢𝑡𝑒𝑑 𝑏𝑦 𝑡ℎ𝑒 𝑇𝑒𝑠𝑡
𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑆𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡 𝑖𝑛 𝑡ℎ𝑒 𝑐𝑜𝑑𝑒
𝑥 100

TM
 A fundamental strength that all white-box techniques share is that the entire software implementation is taken into
account during testing, which facilitates defect detection even when the software specification is vague, outdated or
incomplete.
 A corresponding weakness is that if the software does not implement one or more requirements, white box testing may
not detect the resulting defects of omission.
 White-box techniques can be used in static testing (e.g., during dry runs of code). They are well suited to reviewing code
that is not yet ready for execution, as well as pseudocode and other high level or top-down logic which can be modeled
with a control flow graph.
 Performing only black-box testing does not provide a measure of actual code coverage.
 White-box coverage measures provide an objective measurement of coverage and provide the necessary information to
allow additional tests to be generated to increase this coverage, and subsequently increase confidence in the code.
The Value of White Box Testing

TM
 Experience Based techniques uses tester’s skill, intuition and experience of similar application and technologies.
 These techniques are useful in identifying special tests which are not easily captured by formal techniques.
 These techniques are usually applied after applying formal techniques.
 There are few scenarios where these are the only option to applied.
 Specifications are poorly defined.
 Time Pressure.
 Testing team is not formally trained on testing fundamentals.
Introduction to Experience Based Techniques

TM
 This techniques requires knowledge of defects and experience of application.
 Is to enumerate possible defects and design tests that attack these defects.
 This systematic approach is called Fault Attack.
 These defect and failure list can be built based on experience, typical defect and failure data.
 Updating the result of execution and evaluating further need of tests and their execution.
 Error guessing based on
 How the application has worked in the past
 What types of mistakes the developers tend to make
 Failures that have occurred in other applications
Error Guessing

TM
 In exploratory testing, tests are simultaneously designed, executed, and evaluated while the tester learns about the test
object.
 The testing is used to learn more about the test object, to explore it more deeply with focused tests, and to create tests
for untested areas.
 Exploratory testing is sometimes conducted using session-based testing to structure the testing. In a session-based
approach, exploratory testing is conducted within a defined time-box. The tester uses a test charter containing test
objectives to guide the testing.
 The test session is usually followed by a debriefing that involves a discussion between the tester and stakeholders
interested in the test results of the test session.
 In this approach test objectives may be treated as high-level test conditions.
 Coverage items are identified and exercised during the test session. The tester may use test session sheets to document
the steps followed and the discoveries made. Exploratory testing is useful when there are few or inadequate
specifications or there is significant time pressure on the testing.
 Exploratory testing is also useful to complement other more formal test techniques. Exploratory testing will be more
effective if the tester is experienced, has domain knowledge and has a high degree of essential skills, like analytical
skills, curiosity and creativeness
Exploratory Testing

TM
 In checklist-based testing, a tester designs, implements, and executes tests to cover test conditions from a checklist.
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 should not contain items that can be checked automatically, items better suited as entry/exit criteria, or
items that are too general.
 Checklist items are often phrased in the form of a question. It should be possible to check each item separately and
directly. These items may refer to requirements, graphical interface properties, quality characteristics or other forms of
test conditions.
 Checklists can be created to support various test types, including functional and non-functional testing.
 Some checklist entries may gradually become less effective over time because the developers will learn to avoid making
the same errors. New entries may also need to be added to reflect newly found high severity defects. Therefore,
checklists should be regularly updated based on defect analysis.
 However, care should be taken to avoid letting the checklist become too long.
 In the absence of detailed test cases, checklist-based testing can provide guidelines and some degree of consistency for
the testing. If the checklists are high-level, some variability in the actual testing is likely to occur, resulting in potentially
greater coverage but less repeatability.
Checklist Based Testing

TM
 A user story represents a feature that will be valuable to either a user or purchaser of a system or software.
 User stories have three critical aspects, called together the “3 C’s”:
 Card – the medium describing a user story (e.g., an index card, an entry in an electronic board)
 Conversation – explains how the software will be used (can be documented or verbal)
 Confirmation – the acceptance criteria
 The most common format for a user story is “As a [role], I want [goal to be accomplished], so that I can [resulting
business value for the role]”, followed by the acceptance criteria.
 Collaborative authorship of the user story can use techniques such as brainstorming and mind mapping. The
collaboration allows the team to obtain a shared vision of what should be delivered, by taking into account three
perspectives: business, development and testing.
 Good user stories should be: Independent, Negotiable, Valuable, Estimable, Small and Testable (INVEST). If a
stakeholder does not know how to test a user story, this may indicate that the user story is not clear enough, or that it
does not reflect something valuable to them, or that the stakeholder just needs help in testing.
Collaborative User Story Writing

TM
 Acceptance criteria for a user story are the conditions that an implementation of the user story must meet to be
accepted by stakeholders. From this perspective, acceptance criteria may be viewed as the test conditions that should
be exercised by the tests.
 Acceptance criteria are usually a result of the Conversation. Acceptance criteria are used to:
 Define the scope of the user story
 Reach consensus among the stakeholders
 Describe both positive and negative scenarios
 Serve as a basis for the user story acceptance testing
 Allow accurate planning and estimation
 There are several ways to write acceptance criteria for a user story. The two most common formats are:
 Scenario-oriented (e.g., Given/When/Then format used in BDD)
 Rule-oriented (e.g., bullet point verification list, or tabulated form of input-output mapping)
 Most acceptance criteria can be documented in one of these two formats. However, the team may use another, custom
format, as long as the acceptance criteria are well-defined and unambiguous.
Acceptance Criteria

TM
 ATDD is a test-first approach. Test cases are created prior to implementing the user story. The test cases are created by
team members with different perspectives, e.g., customers, developers, and testers.
 Test cases may be executed manually or automated. The first step is a specification workshop where the user story and
(if not yet defined) its acceptance criteria are analyzed, discussed, and written by the team members. Incompleteness,
ambiguities, or defects in the user story are resolved during this process.
 The next step is to create the test cases. This can be done by the team as a whole or by the tester individually. The test
cases are based on the acceptance criteria and can be seen as examples of how the software works. This will help the
team implement the user story correctly.
 Since examples and tests are the same, these terms are often used interchangeably.
 During the test design the test techniques may be applied.
Acceptance Test-driven Development (ATDD)

TM
 Typically, the first test cases are positive, confirming the correct behavior without exceptions or error conditions, and
comprising the sequence of activities executed if everything goes as expected.
 After the positive test cases are done, the team should perform negative testing. Finally, the team should cover non-
functional quality characteristics as well (e.g., performance efficiency, usability). Test cases should be expressed in a
way that is understandable for the stakeholders.
 Typically, test cases contain sentences in natural language involving the necessary preconditions (if any), the inputs,
and the postconditions. The test cases must cover all the characteristics of the user story and should not go beyond the
story. However, the acceptance criteria may detail some of the issues described in the user story.
 In addition, no two test cases should describe the same characteristics of the user story. When captured in a format
supported by a test automation framework, the developers can automate the test cases by writing the supporting code
as they implement the feature described by a user story.
 The acceptance tests then become executable requirements.
Acceptance Test-driven Development (ATDD)

TM
1. Which of the following is a characteristic of experience-based test techniques?
Answer Set
A. Test cases are created based on detailed design information
B. Items tested within the interface code section are used to measure coverage
C. The techniques heavily rely on the tester’s knowledge of the software and the business domain
D. The test cases are used to identify deviations from the requirements
Sample Questions

TM
2. Your test suite achieved 100% statement coverage. What is the consequence of this fact?
Answer Set
A. Each instruction in the code that contains a defect has been executed at least once
B. Any test suite containing more test cases than your test suite will also achieve 100% statement coverage
C. Each path in the code has been executed at least once
D. Every combination of input values has been tested at least once
Sample Questions

TM
3. Which of the following BEST describes the way acceptance criteria can be documented?
Answer Set
A. Performing retrospectives to determine the actual needs of the stakeholders regarding a given user story
B. Using the given/when/then format to describe an example test condition related to a given user story
C. Using verbal communication to reduce the risk of misunderstanding the acceptance criteria by others
D. Documenting risks related to a given user story in a test plan to facilitate the risk-based testing of a given user story
Sample Questions

Chapter 4 - Test Analysis & Design Techniques V4.0

More Related Content

What's hot

Similar to Chapter 4 - Test Analysis & Design Techniques V4.0

More from Neeraj Kumar Singh

Recently uploaded

In this document

Chapter 4 - Test Analysis & Design Techniques V4.0