4.2.3.

Decision Table Testing Decision tables are used for testing the
implementation of requirements that specify how different combinations of
conditions result in different outcomes. Decision tables are an effective
way of recording complex logic, such as business rules. When creating
decision tables, the conditions and the resulting actions of the system are
defined. These form the rows of the table. Each column corresponds to a
decision rule that defines a unique combination of conditions, along with
the associated actions. In limited-entry decision tables all the values of the
conditions and actions (except for irrelevant or infeasible ones; see below)
are shown as Boolean values (true or false). Alternatively, in extended-
entry decision tables some or all the conditions and actions may also take
on multiple values (e.g., ranges of numbers, equivalence partitions,
discrete values). The notation for conditions is as follows: “T” (true) means
that the condition is satisfied. “F” (false) means that the condition is not
satisfied. “–” means that the value of the condition is irrelevant for the
action outcome. “N/A” means that the condition is infeasible for a given
rule. For actions: “X” means that the action should occur. Blank means that
the action should not occur. Other notations may also be used. A full
decision table has enough columns to cover every combination of
conditions. The table can be simplified by deleting columns containing
infeasible combinations of conditions. The table can also be minimized by
merging columns, in which some conditions do not affect the outcome,
into a single column. Decision table minimization algorithms are out of
scope of this syllabus. In decision table testing, the coverage items are the
columns containing feasible combinations of conditions. To achieve 100%
coverage with this technique, test cases must exercise all these columns.
Coverage is measured as the number of exercised columns, divided by the
total number of feasible columns, and is expressed as a percentage. The
strength of decision table testing is that it provides a systematic approach
to identify all the combinations of conditions, some of which might
otherwise be overlooked. It also helps to find any gaps or contradictions in
the requirements. If there are many conditions, exercising all the decision
rules may be time consuming, since the number of rules grows
exponentially with the number of conditions. In such a case, to reduce the
number of rules that need to be exercised, a minimized decision table or a
riskbased approach may be used. 4.2.4. State Transition Testing A state
diagram models the behavior of a system by showing its possible states
and valid state transitions. A transition is initiated by an event, which may
be additionally qualified by a guard condition. The transitions are assumed
to be instantaneous and may sometimes result in the software taking
action. The common transition labeling syntax is as follows: “event [guard
condition] / action”. Guard conditions and actions can be omitted if they do
not exist or are irrelevant for the tester. A state table is a model equivalent
to a state diagram. Its rows represent states, and its columns represent
events (together with guard conditions if they exist). Table entries (cells)
represent transitions, and contain the target state, as well as the resulting
actions, if defined. In contrast to the state diagram, the state table
explicitly shows invalid transitions, which are represented by empty cells.
A test case based on a state diagram or state table is usually represented
as a sequence of events, which results in a sequence of state changes
(and actions, if needed). One test case may, and usually will, cover several
transitions between states. There exist many coverage criteria for state
transition testing. This syllabus discusses three of them. Certified Tester
Foundation Level v4.0.1 Page 42 of 78 2024-09-15 © International
Software Testing Qualifications Board In all states coverage, the coverage
items are the states. To achieve 100% all states coverage, test cases must
ensure that all the states are exercised. Coverage is measured as the
number of exercised states divided by the total number of states and is
expressed as a percentage. In valid transitions coverage (also called 0-
switch coverage), the coverage items are single valid transitions. To
achieve 100% valid transitions coverage, test cases must exercise all the
valid transitions. Coverage is measured as the number of exercised valid
transitions divided by the total number of valid transitions and is
expressed as a percentage. In all transitions coverage, the coverage items
are all the transitions shown in a state table. To achieve 100% all
transitions coverage, test cases must exercise all the valid transitions and
attempt to execute invalid transitions. Testing only one invalid transition in
a single test case helps to avoid defect masking, i.e., a situation in which
one defect prevents the detection of another. Coverage is measured as the
number of valid and invalid transitions exercised or attempted to be
covered by executed test cases, divided by the total number of valid and
invalid transitions, and is expressed as a percentage. All states coverage is
weaker than valid transitions coverage, because it can typically be
achieved without exercising all the transitions. Valid transitions coverage is
the most widely used coverage criterion. Achieving full valid transitions
coverage guarantees full all states coverage. Achieving full all transitions
coverage guarantees both full all states coverage and full valid transitions
coverage and should be a minimum requirement for mission and safety-
critical software. 4.3. White-Box Test Techniques 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 white-box test techniques that are used in some safety-critical,
mission-critical, or high-integrity environments to achieve more thorough
code coverage. There are also white-box test techniques used in higher
test levels (e.g., API testing), or using coverage not related to code (e.g.,
neuron coverage in neural network testing). These techniques are not
discussed in this syllabus. 4.3.1. Statement Testing and Statement
Coverage In statement testing, the coverage items are executable
statements. The aim is to design test cases that exercise statements in the
code until an acceptable level of coverage is achieved. Coverage is
measured as the number of statements exercised by the test cases
divided by the total number of executable statements in the code, and is
expressed as a percentage. When 100% statement coverage is achieved,
it ensures that all executable statements in the code have been exercised
at least once. In particular, this means that each statement with a defect
will be executed, which may cause a failure demonstrating the presence of
the defect. However, exercising a statement with a test case will not
detect defects in all cases. For example, it may not detect defects that are
data dependent (e.g., a division by zero that only fails when a denominator
is set to zero). Also, 100% statement coverage does not ensure that all the
decision logic has been tested as, for instance, it may not exercise all the
branches (see chapter 4.3.2) in the code. Certified Tester Foundation Level
v4.0.1 Page 43 of 78 2024-09-15 © International Software Testing
Qualifications Board 4.3.2. Branch Testing and Branch Coverage A branch
is a transfer of control between two nodes in the control flow graph, which
shows the possible sequences in which source code statements are
executed in the test object. Each transfer of control can be either
unconditional (i.e., straight-line code) or conditional (i.e., a decision
outcome). In branch testing the coverage items are branches and the aim
is to design test cases to exercise branches in the code until an acceptable
level of coverage is achieved. Coverage is measured as the number of
branches exercised by the test cases divided by the total number of
branches and is expressed as a percentage. When 100% branch coverage
is achieved, all branches in the code, unconditional and conditional, are
exercised by test cases. Conditional branches typically correspond to a
true or false outcome from an “if...then” decision, an outcome from a
switch/case statement, or a decision to exit or continue in a loop.
However, exercising a branch with a test case will not detect defects in all
cases. For example, it may not detect defects requiring the execution of a
specific path in a code. Branch coverage subsumes statement coverage.
This means that any set of test cases achieving 100% branch coverage
also achieves 100% statement coverage (but not vice versa). 4.3.3. The
Value of White-box Testing A fundamental strength that all white-box test
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 (Watson 1996). White-box test techniques can be used in static
testing (e.g., during dry runs of code). They are well suited to reviewing
code not yet ready for execution (Hetzel 1988), 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 the necessary information to allow
additional tests to be generated to increase this coverage, and
subsequently increase confidence in the code. 4.4. Experience-based Test
Techniques Commonly used experience-based test techniques discussed in
the following sections are: • Error guessing • Exploratory testing •
Checklist-based testing 4.4.1. Error Guessing Error guessing is a test
technique used to anticipate the occurrence of errors, defects, and
failures, based

• 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 (see section 4.5.3) • 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, see section
2.1.3) • 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. 4.5.3. Acceptance Test-driven Development (ATDD) ATDD is
a test-first approach (see section 2.1.3). 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 (Adzic
2009). 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
described in sections 4.2, 4.3 and 4.4 may be applied. 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 (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. Certified
Tester Foundation Level v4.0.1 Page 47 of 78 2024-09-15 © International
Software Testing Qualifications Board 5. Managing the Test Activities – 335
minutes Keywords defect management, defect report, entry criteria, exit
criteria, product risk, project risk, risk, risk analysis, risk assessment, risk
control, risk identification, risk level, risk management, risk mitigation, risk
monitoring, risk-based testing, test approach, test completion report, test
control, test monitoring, test plan, test planning, test progress report, test
pyramid, test strategy, testing quadrants Learning Objectives for Chapter
5: 5.1 Test Planning FL-5.1.1 (K2) Exemplify the purpose and content of a
test plan FL-5.1.2 (K1) Recognize how a tester adds value to iteration and
release planning FL-5.1.3 (K2) Compare and contrast entry criteria and exit
criteria FL-5.1.4 (K3) Use estimation techniques to calculate the required
test effort FL-5.1.5 (K3) Apply test case prioritization FL-5.1.6 (K1) Recall
the concepts of the test pyramid FL-5.1.7 (K2) Summarize the testing
quadrants and their relationships with test levels and test types 5.2 Risk
Management FL-5.2.1 (K1) Identify risk level by using risk likelihood and
risk impact FL-5.2.2 (K2) Distinguish between project risks and product
risks FL-5.2.3 (K2) Explain how product risk analysis may influence
thoroughness and test scope FL-5.2.4 (K2) Explain what measures can be
taken in response to analyzed product risks 5.3 Test Monitoring, Test
Control and Test Completion FL-5.3.1 (K1) Recall metrics used for testing
FL-5.3.2 (K2) Summarize the purposes, content, and audiences for test
reports FL-5.3.3 (K2) Exemplify how to communicate the status of testing
5.4 Configuration Management FL-5.4.1 (K2) Summarize how configuration
management supports testing 5.5 Defect Management FL-5.5.1 (K3)
Prepare a defect report Certified Tester Foundation Level v4.0.1 Page 48 of
78 2024-09-15 © International Software Testing Qualifications Board 5.1.
Test Planning 5.1.1. Purpose and Content of a Test Plan A test plan
describes the test objectives, resources and processes for a test project. A
test plan: • Documents the means and schedule for achieving test
objective