This document discusses decision table-based testing (DTT) as a black box testing technique. DTT uses decision tables to systematically test all combinations of inputs and conditions to derive corresponding outputs and actions. The document provides examples of using decision tables to test a bank debiting software and an ATM transaction system. It shows sample decision tables listing conditions, rules representing test cases, and expected actions. DTT allows generating test cases to achieve complete coverage of each column in the decision table. While thorough, this approach can result in an exponential number of test cases as more conditions are added.

1. SOFTWARE
TESTING & QA
Lectire7- Black Box
testing (Decision Table
Testing)
1

2. DECISION-TABLE-BASED
TESTING
Decision tables are a simple formalism to describe how
different combinations of inputs may generate different outputs.
Decision tables find practical us particularly in data processing
applications. Their tabular form makes them easy to
understand and supports a systematic derivation of tests

3. DECISION TABLE-BASED
TESTING (DTT)
Applicable to the software requirements written using “if-then”
statements
Can be automatically translated into code
Assume the independence of inputs
Example
 If c1 AND c2 OR c3 then A1
 c1, c2 and c3 are conditions while A1 is an action

4. CONDITIONS (CAUSES)
AND ACTIONS
(EFFECTS)
A CONDITION or CAUSE may be thought of as a distinct input
condition, or an “equivalence class” of input conditions.
An ACTON or EFFECT may be thought of as a distinct output
condition or change in program state.

5. DECISION-TABLE-BASED
TESTING
One can generate test cases naturally on the basis of the
decision table, trying to apply the complete coverage criteria so
that each column of the table is exercised by at least one test
This technique may be too expensive in terms of the number of
experiments to be carried out, because of the exponential
growth in the number of test cases with respect to the number
of conditions
In fact, in general, the number of columns can go up to 2n,
where n is the number of conditions

6. SAMPLE OF DECISION
TABLE
A decision table is consists of a
number of columns (rules) that
comprise all test situations.
C1, C2..Cn are conditions
(Causes)
A1, A2…An are actions (Effects)
R1, R2,…Rm are Rules (test
cases)
Action A1 will take place if c1 and
c2 are true (or satisfied)
1: means the condition is true.
0: means the condition is false.
x: don’t care.
R1 R2 Rm
C1 1 1 0
C2 1 0 0
x x 1
Cn 0 0 0
A1 1 0 0
A2 0 1 1
… 0 0 0
An o o 1

7. BANK EXAMPLE
Consider a bank software responsible for debiting from an
account. The relevant conditions and actions are:
 C1: The account number is correct
 C2: The signature matches
 C3: There is enough money in the account
 A1: Give money
 A2: Give statement indicating insufficient funds
 A3: Call vigilance to check for fraud!

8. BANK EXAMPLE-
CONTINUED
A1 is to be performed when C1, C2, and C3 are true.
A2 is to be performed when C1 is true and C2 and C3 are false
or when C1 and C2 are true and C3 is false.
A3 is to be performed when C2 and C3 are false.

9. R1 R2 R3 R4
C1 1 1 1 0
C2 1 1 0 0
C3 1 0 0 x
A1 1 0 0 0
A2 0 1 1 0
A3 0 0 0 1
DECISION TABLES FOR
BANK EXAMPLE

10. BANK EXAMPLE-CONT..
What are the appropriate
test cases for this
problem? Check the rules
10

11. EXAMPLE(2): ATM
For a simple ATM banking transaction
system
 Causes (Conditions)
 C1: Command is credit
 C2: command is debit
 C3: account number is valid
 C4: transaction amount is valid
 Effects (Actions)
 A1: Print “invalid command”
 A2: Print “ invalid account number”
 A3: Print “debit amount not valid”
 A4: debit account
 A5: Credit account

12. ATM CAUSE-EFFECT
DECISION TABLE
C R1 R2 R3 R4 R5
C1 0 1 x x 1
C2 0 x 1 1 x
C3 x 0 1 1 1
C4 x x 0 1 1
A1 1 0 0 0 0
A2 0 1 0 0 0
A3 0 0 1 0 0
A4 0 0 0 1 0
A5 0 0 0 0 1

13. ANOTHER HOMEWORK
ON DT
Consider an e-commerce application. At the user interface layer, we need to validate payment information,
specifically credit card type, card number, card security code, expiration month, expiration year, and cardholder
name. You can use boundary value analysis and equivalence partitioning to test the ability of the application to
verify the payment information, as much as possible, before sending it to the server. So, once that information goes
to the credit card processing company for validation,
how can we test that? Again, we could handle that with equivalence partitioning, but there are actually a whole set
of conditions that determine this processing: Does the named person hold the credit card entered, and is the other
information
correct?
Is it still active or has it been cancelled?
Is the person within or over their limit?
Is the transaction coming from a normal or a suspicious location?
The decision table in Table 1 shows how these four conditions interact to determine
which of the following three actions will occur:
Should we approve the transaction?
Should we call the cardholder (e.g., to warn them about a purchase from a strange place)?
Should we call the vendor (e.g., to ask them to seize the cancelled card)?
13