Scribd
Upload
5 views

06 Decision Tables_Done

SOFTWARE TESTING

Uploaded by

abbastayyaba417
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
5 views

06 Decision Tables_Done

SOFTWARE TESTING

Uploaded by

abbastayyaba417
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 27

SOFTWARE

TESTING
(DECISION
TABLES)
Engr. Sajid Saleem
OUTLINE
 Decision table
 LEDTs
 EEDTs
 Decision with Multiple Actions
 Decision Tables to Test Case Table
 Applicability and Limitations
 Example
 Triangle Problem
 Buy Order Problem
 Amount Withdrawal Problem
2
DECISION TABLES
DECISION TABLES
 Decision tables represent complex business rules based on a set of conditions.
DECISION TABLES
 Conditions 1 through m represent various input conditions.

 Actions 1 through n are the actions that should be taken depending on the various combinations
of input conditions.
 Each of the rules defines a unique combination of conditions that result in the execution ("firing")
of the actions associated with that rule.
DECISION TABLES
 Perhaps a concrete example will clarify the concepts:

 An auto insurance company gives discounts to drivers who are married and/or good
students.
 Let's begin with the conditions. The following decision table has two conditions, each
one of which takes on the values Yes or No.
DECISION TABLES
 As a tester we will verify that all combinations of the conditions that are defined. Missing a
combination may result in developing a system that may not process a particular set of inputs
properly.
 Now for the actions. Each rule causes an action to "fire." Each rule may specify an action
unique to that rule, or rules may share actions.
DECISION TABLES (LEDTS
AND EEDTS)
 In this situation, choosing test cases is simple—each rule (vertical column) becomes a test case.

 The Conditions specify the inputs and the Actions specify the expected results.

 A decision table is a good way to deal with combinations of things (e.g. inputs).

 This technique is sometimes also referred to as a 'cause-effect' table.

 Decision tables in which all the conditions are binary are called Limited Entry Decision
Tables (LEDTs).

 If conditions are allowed to have several values, the resulting tables are called Extended
Entry Decision Tables (EEDTs).
DECISION TABLES WITH
MULTIPLE ACTIONS (EEDT)
 In this situation choosing test cases is slightly more complex— each rule (vertical
column) becomes a test case but values satisfying the conditions must be chosen.
SHIPPING COST
CALCULATOR
TEST CASES BASED ON
DECISION TABLES WITH
MULTIPLE ACTIONS
 Choosing appropriate values we create the following test cases:
DECISION TABLES
 In testing, create at least one test case for each rule.

 If the rule's conditions are binary, a single test for each combination is probably sufficient.

 On the other hand, if a condition is a range of values, consider testing at both the low and high
end of the range.
 In this way we merge the ideas of Boundary Value testing with Decision Table testing.
DECISION TABLES TO TEST
CASE TABLE
APPLICABILITY AND
LIMITATIONS
 Decision Table testing can be used:
 whenever the system must implement complex business rules
 when these rules can be represented as a combination of conditions and
 when these conditions have discrete actions associated with them.
ACTIVITY – TRIANGLE
PROBLEM
 One helpful style is to add an action to show when a rule is logically impossible.

 In the decision table in Table 7.2, we see examples of don’t care entries and
impossible rule usage.
 If the integers a, b, and c do not constitute a triangle, we do not even care about
possible equalities, as indicated in the first rule.
 In rules 3, 4, and 6, if two pairs of integers are equal, by transitivity, the third pair
must be equal; thus, the negative entry makes these rules impossible.
PLACE ‘X’ IN THE RIGHT
ACTION CELL
Scalene Triangle: has
all its sides of different
lengths
Isosceles Triangle:
has two sides of equal
length.
Equilateral Triangle:
has all sides of equal
length.
SOLUTION – TRIANGLE
PROBLEM
TEST CASE TABLE -
TRIANGLE PROBLEM
 We obtain 11 functional test cases:
 three impossible cases,
 three ways to fail the triangle
property,
 one way to get an equilateral
triangle,
 one way to get a scalene triangle,
and
 three ways to get an isosceles
triangle

 We still need to provide actual values


for the variables in the conditions, but
we cannot do this for the impossible
rules.
ACTIVITY – BUY ORDER
 Consider a Trade Web page of the Brown & Donaldson Web site with the following
rules associated with a Buy order.
ACTIVITY – BUY ORDER
 Examine the first four columns. If the Symbol is not valid, none of the other
conditions matter.
 Often tables like this are collapsed, rules are combined, and the conditions that do
not affect the outcome are marked "DC" for "Don't Care."
 Rule 1 now indicates that if the Symbol is not valid, ignore the other conditions and
do not execute the Buy order.

Note also that


Rule 2 and Rule 3
can be combined
because whether
Sufficient Funds
are available does
not affect the
action.
ACTIVITY – BUY ORDER

 While this is an excellent idea from a development standpoint because less code is written, it
is dangerous from a testing standpoint.
 It is always possible that the table was collapsed incorrectly or the code was written
improperly.
 The un-collapsed table should always be used as the basis for our test case design.
ACTIVITY – AMOUNT
WITHDRAWAL
 Requirement: “Withdrawal is granted if requested amount is covered by the
balance or if the customer is granted credit to cover the withdrawal
amount”.

 Identify conditions
 Withdrawal using Balance
 Withdrawal using Credit

 Identify actions
 Withdrawal Granted

 Draw the rule columns! - how many columns….. 2Conditions


 22 or 23 ?
REDUCE THE TABLE BY POINTING OUT
THE TERMS WHICH CAN BE IGNORED IN
CERTAIN SCENARIO.
NOW DETERMINE ACTIONS
STEP 5: WRITE TEST CASES
 Write test cases based on the table. At least one test case per column
gives full coverage of all business rules.

 Test case for R1: balance = 200, requested withdrawal = 200. Expected
result: withdrawal granted.
 Test case for R2: balance = 100, requested withdrawal = 200, credit
granted. Expected result: withdrawal granted.
 Test case for R3: balance = 100, requested withdrawal = 200, no credit.
Expected Result: withdrawal denied.
THANK YOU

You might also like