Discussion Contents

Black Box Testing:

 Boundary Value Analysis (BVA)
 Equivalence Class Testing
 State Table based Testing
 Decision Table based Testing
 Cause-Effect Graphing based Testing
 Error Guessing

3
Black Box Testing
Introduction:

Figure 4.1 Black-box Testing.

Black-box testing attempts to find errors in the following categories:

 To test the modules independently
 To test the functional validity of the software so that incorrect or missing functions can be
recognized
 To look for interface errors
 To test the system behavior and check its performance
 To test the maximum load or stress on the system
 To test the software such that the user/customer accepts the system within defined
acceptable limits
Boundary Value Analysis (BVA)
Effective test case design requires test cases to be designed such that they
maximize the probability of finding errors.
BVA is considered a technique that uncovers the bugs at the boundary of input values.
Here, boundary means the maximum or minimum value taken by the input domain.
For example, in the figure below, if A is an integer between 10 and 255, then boundary
checking can be on 10(9,10,11) and on 255(256,255,254). Similarly, B is another integer
variable between 10 and 100, then boundary checking can be on 10(9,10,11) and
100(99,100,101).
Figure 4.2 Boundary Value Analysis

Boundary Values Analysis (BVA) Methods:

Boundary Value Checking, Robust Testing Method, Worst-Case Testing Method.
Boundary Value Analysis (BVA)
1. Boundary Value Checking (BVC):
In this method, the test cases are designed by holding one variable at its extreme value and
other variables at their nominal values in the input domain.
The variable at its extreme value can be selected at: Figure 4.3 Boundary Value Checking

(a) Minimum value (Min)

(b)Value just above the minimum value (Min+ )
(c) Maximum value (Max)
(d)Value just below the maximum value (Max−)

Consider an example of two variables, A and B. If we consider all the above combinations with
Nominal values, then following test cases (see Fig. 4.3) can be designed:
1. Anom, Bmin 4. Anom, Bmax– 7. Amax, Bnom
2. Anom, Bmin+ 5. Amin, Bnom 8. Amax–, Bnom
3. Anom, Bmax 6. Amin+, Bnom 9. Anom, Bnom
For n variables in a module, 4n + 1 test cases can be designed with BVC method.
Boundary Value Analysis (BVA)
2. Robust Testing Method:
When test cases are designed considering the below points in addition to BVC, it is called
Robustness testing.
In the previous example of two variables, A and B, the following test cases are added.

1. Anom, Bmin 4. Anom, Bmax– 7. Amax, Bnom 10. Amax+, Bnom 13. Anom, Bmin–
2. Anom, Bmin+ 5. Amin, Bnom 8. Amax–, Bnom 11. Amin–, Bnom
3. Anom, Bmax 6. Amin+, Bnom 9. Anom, Bnom 12. Anom, Bmax+

For n input variables in a module, 6n + 1 test cases can be designed with Robustness Testing.
Boundary Value Analysis (BVA)
3. Worst Case Testing Method:
If extended the concept of BVC by assuming more than one variable on the boundary. It is
called Worst Case Testing.
In the previous example of two variables, A and B, the following test cases are added:

1. Anom, Bmin 6. Amin+, Bnom 11. Amin+, Bmin 16. Amax, Bmin+ 21. Amin+, Bmax-
2. Anom, Bmin+ 7. Amax, Bnom 12. Amin, Bmin+ 17. Amax-, Bmin+ 22. Amax, Bmax
3. Anom, Bmax 8. Amax–, Bnom 13. Amin+, Bmin+ 18. Amin, Bmax 23. Amax-, Bmax
4. Anom, Bmax– 9. Anom, Bnom 14. Amax, Bmin 19. Amin+, Bmax 24. Amax, Bmax-
5. Amin, Bnom 10. Amin, Bmin 15. Amax-, Bmin 20. Amin, Bmax- 25. Amax-, Bmax-
for n input variables in a module, 5n test cases can be designed with Worst Case Testing.
Boundary Value Analysis (BVA)
Example 1: A program reads an integer number within the range [1,100] and determines whether it
is a prime number or not. Design test cases for this program using BVC, Robust Testing, andWorst Case
Testing methods.
i. Test cases using BVC:
Only ONE variable is used; Hence, total no. of test cases = 4n+1 = 4(1)+1 = 5
Min, Max & Nominal values: Min = 1, Min+ = 2, Max = 100, Max- = 99, Nom = 50 to 55
Hence, Test cases are: Test case ID Integer Value Expected Output
1 1 Not a Prime Number
2 2 Prime Number
3 100 Not a Prime Number
4 99 Not a Prime Number
5 53 Prime Number

ii. Test cases using Robust Testing:

Only ONE variable is used; Hence, total no. of test cases = 6n+1 = 6(1)+1 = 7
Boundary Value Analysis (BVA)
ii. Test cases using Robust Testing:
Only ONE variable is used; Hence, total no. of test cases = 6n+1 = 6(1)+1 = 7
Min, Max & Nominal values: Min = 1, Min- = 0, Min+ = 2, Max = 100, Max- = 99,
Max+ = 101, Nom = 50 to 55
Hence, Test cases are: Test case ID Integer Value Expected Output
1 0 Invalid Input
2 1 Not a Prime Number
3 2 Prime Number
4 100 Not a Prime Number
5 99 Not a Prime Number
6 101 Invalid Input
7 53 Prime Number

iii. Test cases using Worst Case Testing:

Only ONE variable is used; Hence, total no. of test cases = 5n = 51= 5
Hence, Test cases are same as BVC.
Boundary Value Analysis (BVA)
Example 2: A program computes ab where a lies in the range [1,10] and b within [1,5]. Design test
cases for this program using BVC, Robust Testing, andWorst Case Testing methods.
i. Test cases using BVC: Min, Max & Nom values: Boundaries a b
Min 1 1
TWO variables used;
Min+ 2 2
Hence, total no. of test cases = 4n+1 = 4(2)+1 = 9
Max 10 5
Hence, Test cases are: Max- 9 4
Test case ID a b Expected Output
Nom 5 3
1 1 3 1
2 2 3 8
3 10 3 1000
4 9 3 729
5 5 1 5
6 5 2 25
7 5 5 3125
8 5 4 625
9 5 3 125
 Boundary Value Analysis (BVA)
Example 2: A program computes ab where a lies in the range [1,10] and b within [1,5]. Design test
cases for this program using BVC, Robust Testing, andWorst Case Testing methods.
ii. Test cases using Robust Testing: Min, Max & Nom values: Boundaries a b
Min 1 1
TWO variables used;
Min- 0 0
Hence, total no. of test cases = 6n+1 = 6(2)+1 = 13
Min+ 2 2
Max 10 5
Max+ 11 6
Max- 9 4
Hence, Test cases are:
Nom 5 3
Test case ID a b Expected Output
1 0 3 Invalid Input Test case ID a b Expected Output
2 1 3 1 8 5 1 5
3 2 3 8 9 5 2 25
4 10 3 1000 10 5 4 625
5 11 3 Invalid Input 11 5 5 3125
6 9 3 729 12 5 6 Invalid Input
7 5 0 Invalid Input 13 5 3 125
Boundary Value Analysis (BVA)
Example 2: A program computes ab where a lies in the range [1,10] and b within [1,5]. Design test
cases for this program using BVC, Robust Testing, andWorst Case Testing methods.
iii. Test cases using Worst Case Testing: Min, Max & Nom values: Boundaries a b
Min 1 1
TWO variables used;
Min+ 2 2
Hence, total no. of test cases = 5n = 52 = 25
Max 10 5
Hence, Test cases are: Max- 9 4
Test case ID a b Expected Output
Nom 5 3
1 1 1 1
2 1 2 1
3 1 3 3
4 1 4 1
5 1 5 1
6 2 1 2
7 2 2 4
8 2 3 8
9 2 4 16
10 2 5 32
Boundary Value Analysis (BVA)
Example 2: A program computes ab where a lies in the range [1,10] and b within [1,5]. Design test
cases for this program using BVC, Robust Testing, andWorst Case Testing methods.
iii. Test cases using Worst Case Testing:

Hence, Test cases are:

Test case ID a b Expected Output Test case ID a b Expected Output
11 5 1 2 21 10 1 10
12 5 2 25 22 10 2 100
13 5 3 125 23 10 3 1000
14 5 4 625 24 10 4 10000
15 5 5 3125 25 10 5 100000
16 9 1 9
17 9 2 81
18 9 3 729
19 9 4 6561
20 9 5 59049
Equivalence Class Testing
Equivalence partitioning is a method for deriving test cases wherein classes of input
conditions called equivalence classes are identified such that each member of the
class causes the same kind of processing and output to occur. Thus, instead of testing every
input, only one test case from each partitioned class can be executed.
In other words, only one test case in the equivalence class will be sufficient to find errors.
Therefore, instead of taking every value in one domain, only one test case is chosen from
one class.
In this way, testing covers the whole input domain, reducing the total number of test cases.

Goals of Equivalence Partitioning:

1. Completeness.
2. Non-redundancy.

Equivalence Partitioning is conducted in Two Steps:

1. Identify Equivalence Classes.
2. Design Test cases.
Equivalence Class Testing
1. Identification of Equivalence Classes: Whole set of inputs are classified into Two:
1. Valid Equivalence Classes: All valid inputs.
2. Invalid Equivalence Classes: Invalid inputs will help to generate error conditions or
assess the unexpected behaviour of the program.

No thumb rule to classify the inputs as valid or invalid.

Few Guidelines are listed and advised to follow in classifying the inputs.
 If there is no reason to believe that the entire range of an input will be treated in the same
manner, then the range should be split into two or more equivalence classes.
 If a program handles each valid input differently, then define one valid equivalence class per
valid input.
 Boundary value analysis can help in identifying the classes. For example, for an input condition,
say 0 <= a <= 100, one valid equivalent class can be formed from the valid range of a. And with BVA,
two invalid classes that cross the minimum and maximum values can be identified, i.e. a < 0 and a >
100.
 If an input variable can identify more than one category, then for each category, equivalent
classes are to be made. For example, if the input is a character, then it can be an alphabet, a
number, or a special character. So we can make three valid classes for this input and one
invalid class.
Equivalence Class Testing
1. Identification of Equivalence Classes:
 If the requirements state that the number of items input by the system at some point must
lie within a certain range, then specify one valid class where the number of inputs is within
the valid range, one invalid class where there are very few inputs, and one invalid class
where there are too many inputs. For example, specifications state that a maximum of 4 purchase
orders can be registered against a product.The equivalence classes are: the valid equivalence class (1 ≤
no. of purchase orders ≤ 4), the invalid class (no. of purchase orders > 4), and the invalid class (no. of
purchase orders < 1).
 If an input condition specifies a ‘must be’ situation (e.g., ‘first character of the identifier
must be a letter’), identify a valid equivalence class (it is a letter) and an invalid equivalence
class (it is not a letter).
 Equivalence classes can be of the output desired in the program. Determining test cases for
output classes may be more difficult, but output classes have been found to reveal errors that
are not revealed by just considering the input classes.
 Look for membership of an input condition in a set or group and identify valid (within the
set) and invalid (outside the set) classes. For example, if the requirements state that a valid
province code is ON, QU, and NB, then identify: the valid class (code is one of ON, QU, NB) and the
invalid class (code is not one of ON, QU, NB).
Equivalence Class Testing
1. Identification of Equivalence Classes:
 If the requirements state that a particular input item match a set of values and each case will
be dealt with differently, identify a valid equivalence class for each element and only one
invalid class for values outside the set. For example, if a discount code must be input as P for a
preferred customer, R for a standard reduced rate, or N for none, and if each case is treated differently,
identify: the valid class code = P, the valid class code = R, the valid class code = N, the invalid class
code is not one of P, R, N.
 If an element of an equivalence class will be handled differently than the others, divide the
equivalence class to create an equivalence class with only these elements and an equivalence
class with none of these elements. For example, a bank account balance may be from 0 to Rs 10
lakh and balances of Rs 1,000 or more are not subject to service charges. Identify: the valid class: (0 ≤
balance < Rs 1,000), i.e. balance is between 0 and Rs 1,000 – not including Rs 1,000; the valid class:
(Rs 1,000 ≤ balance ≤ Rs 10 lakh, i.e. balance is between Rs 1,000 and Rs 10 lakh inclusive the
invalid class: (balance < 0) the invalid class: (balance > Rs 10 lakh).
Equivalence Class Testing
2. Identification (Design) of Test Cases:
Below Guidelines are to be followed for developing of test cases.
 Assign a unique identification number to each equivalence class.
 Write a new test case covering as many of the uncovered valid equivalence classes as
possible, until all valid equivalence classes have been covered by test cases.
 Write a test case that covers one, and only one, of the uncovered invalid equivalence classes,
until all invalid equivalence classes have been covered by test cases. The reason that invalid
cases are covered by individual test cases is that certain erroneous-input checks mask or
supersede other erroneous-input checks. For instance, if the specification states ‘Enter type of
toys (Automatic, Mechanical, Soft toy) and amount (1–10000)’, the test case [ABC 0] expresses two
error (invalid inputs) conditions (invalid toy type and invalid amount) will not demonstrate the invalid
amount test case, hence the program may produce an output ‘ABC is unknown toy type’ and not bother to
examine the remainder of the input.
Equivalence Class Testing
Example 1. A program reads three numbers, A, B, and C, with a range [1, 50] and prints the largest
number. Design test cases for this program using equivalence class testing technique.
Inputs Valid / Invalid
i. First Partition: Valid & Invalid inputs:
I1 = {<A,B,C> : 1 ≤ A ≤ 50} Valid
I2 = {<A,B,C> : 1 ≤ B ≤ 50} Valid
I3 = {<A,B,C> : 1 ≤ C ≤ 50} Valid
I4 = {<A,B,C> : A < 1} Invalid
I5 = {<A,B,C> : A > 50} Invalid
I6 = {<A,B,C> : B < 1} Invalid
Test cases are: I7 = {<A,B,C> : B > 50} Invalid
Test Expected Class Covered I8 = {<A,B,C> : C < 1} Invalid
A B C
case ID Result by the Test case
I9 = {<A,B,C> : C > 50} Invalid
1 13 25 36 C is greatest I1, I2, I3
2 0 13 45 Invalid I4
3 51 34 17 Invalid I5
4 29 0 18 Invalid I6
5 36 53 32 Invalid I7
6 27 42 0 Invalid I8
7 33 21 51 Invalid I9
Equivalence Class Testing
Example 1. A program reads three numbers, A, B, and C, with a range [1, 50] and prints the largest
number. Design test cases for this program using equivalence class testing technique.
Inputs Valid / Invalid
ii. Second Partition: Possibilities for three
integers, A, B, and C: I1 = {<A,B,C> : A > B, A > C} Valid
I2 = {<A,B,C> : B > A, B > C} Valid
I3 = {<A,B,C> : C > A, C > B} Valid
I4 = {<A,B,C> : A = B, A ≠ C} Valid
I5 = {<A,B,C> : B = C, A ≠ B} Valid
I6 = {<A,B,C> : A = C, C ≠ B} Valid
I7 = {<A,B,C> : A = B = C} Valid
Test cases are:
Test Expected Class Covered
A B C
case ID Result by the Test case
1 25 13 13 A is greatest I1, I5,
2 25 40 25 B is greatest I2, I6,
3 24 24 37 C is greatest I3, I4,
4 25 25 25 All are Equal I7,
 Equivalence Class Testing
Example 2. A program determines the next date in the calendar. Its input is entered in the form of
<ddmmyyyy> with the following range: 1 ≤ mm ≤ 12; 1 ≤ dd ≤ 31; 1900 ≤ yyyy ≤ 2025
Its output would be the next date or an error message Inputs Valid / Invalid
‘invalid date.’ Design test cases for this program I1 = {<m, d, y> : 1 ≤ m ≤ 12} Valid
using equivalence class testing technique. I2 = {<m, d, y> : 1 ≤ d ≤ 31} Valid

Partition based on Valid & Invalid inputs: I3 = {<m, d, y> : 1900 ≤ y ≤ 2025} Valid
I4 = {<m, d, y> : m < 1} Invalid
I5 = {<m, d, y> : m > 12} Invalid
I6 = {<m, d, y> : d < 1} Invalid
Test cases are: I7 = {<m, d, y> : d > 31} Invalid
Test Expected Class Covered I8 = {<m, d, y> : y < 1900} Invalid
mm dd yy
case ID Result by the Test case
I9 = {<m, d, y> : y > 2025} Invalid
1 5 20 1996 20-5-1996 I1, I2, I3
2 0 13 2000 Invalid I4
3 13 13 1950 Invalid I5
4 12 0 2007 Invalid I6
5 6 32 1956 Invalid I7
6 11 15 1899 Invalid I8
7 10 19 2026 Invalid I9
State Table based Testing
Few basic terms:
1.Finite State Machine: An FSM is a behavioural model whose outcome depends upon
both previous and current inputs.
2.State Transition Diagrams / State Graphs: A system or its components may have a
number of states depending on its input and time. States are represented by Nodes and the
inputs causes a state to undergo a change and form into a new state. In such a case, it is said to
have a Transitions occurred. Example:
In the graph, each Arrow Link provides:
i. Transition Events like Admitted, Wait, etc.,
ii. The Resulting output because of the event
Like T1, T4, etc.,

3.State Table: State graphs are difficult to understand, hence convert it into a table, for
better convenience. Its conventions are:
Each row of the table corresponds to a state.
Each column corresponds to an input condition.
The box at the intersection of a row and a column specifies the next state (transition) and
the output, if any.
 State Table based Testing
Few basic terms:
3.State Table:

State / Input I/O or Event I/O or Event Exit

Admit Dispatch Interrupt
Event Wait Wait Over
New Ready / T1 New / T0 New / T0 New / T0 New / T0 New / T0
Ready Ready / T1 Running / T2 Ready / T1 Ready / T1 Ready / T1 Ready / T1
Running Running / T2 Running / T2 Ready / T3 Waiting / T4 Running / T2 Terminated / T6
Waiting Waiting / T4 Waiting / T4 Waiting / T4 Waiting / T4 Ready / T5 Waiting / T4

4.State Table Testing: Its process is as under:

i. Identify the States.
ii. Prepare State Transition Diagram.
iii. Convert State Graph into State Table.
iv. Create Test cases.
State Table based Testing
4. State Table Testing: Test cases originates from the Cell Values:
Test Test Input Expected Results
Case Id Source Current State Event Output Next State
TC1 Cell 1 New Admit T1 Ready
TC2 Cell 2 New Dispatch T0 New
TC3 Cell 3 New Interrupt T0 New
TC4 Cell 4 New I/O Wait T0 New
TC5 Cell 5 New I/O Wait Over T0 New
TC6 Cell 6 New Exit T0 New
TC7 Cell 7 Ready Admit T1 Ready
TC8 Cell 8 Ready Dispatch T2 Running
TC9 Cell 9 Ready Interrupt T1 Ready
TC10 Cell 10 Ready I/O Wait T1 Ready
TC11 Cell 11 Ready I/O Wait Over T1 Ready
TC12 Cell 12 Ready Exit T1 Ready
State Table based Testing
4. State Table Testing: Test cases originates from the Cell Values:
Test Test Input Expected Results
Case Id Source Current State Event Output Next State
TC13 Cell 13 Running Admit T2 Running
TC14 Cell 14 Running Dispatch T2 Running
TC15 Cell 15 Running Interrupt T3 Ready
TC16 Cell 16 Running I/O Wait T4 Waiting
TC17 Cell 17 Running I/O Wait Over T2 Running
TC18 Cell 18 Running Exit T6 Terminated
TC19 Cell 19 Waiting Admit T4 Waiting
TC20 Cell 20 Waiting Dispatch T4 Waiting
TC21 Cell 21 Waiting Interrupt T4 Waiting
TC22 Cell 22 Waiting I/O Wait T4 Waiting
TC23 Cell 23 Waiting I/O Wait Over T5 Ready
TC24 Cell 24 Waiting Exit T4 Waiting
Decision Table based Testing
Some critical behaviour may have to be tested when some combinations of input conditions are
considered in the test cases; and Decision Table based Testing helps in such cases.
Decision table is useful specifically during complex combinations of input conditions and
resulting actions exists. Decision tables strength lies in the logical expressions. Here,
each operand or variable in a logical expression takes only ONE value - TRUE or FALSE.
Rule 1 Rule 2 Rule 3 Rule 4 …
Condition
Decision Table:
Stub
C1 True True False I …
C2 False True False True …
C3 True True True I …
A1 X …
Action
Stub

A2 X X …
A3 X …
Condition stub: It is a list of input conditions for which the complex combination is made.
Action stub: It is a list of resulting actions which will be performed if a combination of input
condition is satisfied.
Condition entry: It is a specific entry in the table corresponding to input conditions
mentioned in the condition stub. When we enter TRUE or FALSE for all input conditions for
a particular combination, then it is called a Rule. Hence, a Rule may be defined as the
combination of conditions produces the resulting action.
Decision Table based Testing
When the condition entry takes only two values—TRUE or FALSE, then it is called Limited
Entry Decision Table. When the condition entry takes several values, then it is called
Extended Entry Decision Table.
In limited entry decision table, condition entry, which has no effect whether it is True or False,
is called a Don’t-Care state or immaterial state (represented by I). The state of a don’t-
care condition does not affect the resulting action.

Action entry: It is the entry in the table for the resulting action to be performed
when one rule (which is a combination of input condition) is satisfied. ‘X’ denotes the action
entry in the table.

The guidelines to develop a decision table:

1. List all actions that can be associated with a specific procedure (or module).
2. List all conditions (or decision made) during execution of the procedure.
3. Associate specific sets of conditions with specific actions, eliminating
impossible combinations of conditions; alternatively, develop every possible permutation
of conditions.
4. Define rules by indicating what action occurs for a set of conditions.
 Decision Table based Testing
Test case design using Decision Tables:
1. Interpret condition stubs as the inputs for the test case.
2. Interpret action stubs as the expected output for the test case.
3. Rule, which is the combination of input conditions, becomes the test case itself.
4. If there are ‘k’ rules over ‘n’ binary conditions, there are at least k test cases & at the
most 2n test cases; in other words, Minimum: “k” and Maximum: “2n” test cases.
Example 1: A program calculates the total salary of an employee with the conditions that if the
working hours are less than or equal to 48, then give normal salary.The hours over 48 on normal working
days are calculated at the rate of 1.25 of the salary. However, on holidays or Sundays, the hours are
calculated at the rate of 2.00 times of the salary. Design test cases using decision table testing.
Rule Rule Rule Test case Working Expected
Condition

Day
1 2 3 ID Hour Result
Stub

C1: Working hours > 48 I F T 1 48 Monday Normal Salary

C2: Holidays or Sundays T F F 2 50 Tuesday 1.25 of Salary
A1: Normal Salary X 3 52 Sunday 2.00 of Salary
Action
Stub

A2: 1.25 of Salary X

A3: 2.00of Salary X
Decision Table based Testing
Example 1: A program calculates the total salary of an employee with the conditions that if the
working hours are less than or equal to 48, then give normal salary.The hours over 48 on normal working
days are calculated at the rate of 1.25 of the salary. However, on holidays or Sundays, the hours are
calculated at the rate of 2.00 times of the salary. Design test cases using decision table testing.
Expanding “I” (Don’t Care / Immaterial) cases:
Condition Rule Rule Rule Rule
Stub 1-1 1-2 2 3
C1: Working hours > 48 F T F T
C2: Holidays or Sundays T T F F
A1: Normal Salary X
Action
Stub

A2: 1.25 of Salary X

A3: 2.00of Salary X X

Test case Working Expected

Day
ID Hour Result
1 48 Monday Normal Salary
2 50 Tuesday 1.25 of Salary
3 52 Sunday 2.00 of Salary
4 30 Sunday 2.00 of Salary
Decision Table based Testing
Example 2: A wholesaler has three commodities to sell and has three types of customers. Discount is given as per the
following procedure: (i) For DGS & D orders, 10% discount is given irrespective of the value of the order. (ii) For orders of
more than Rs 50,000, agents get a discount of 15% and the retailer gets a discount of 10%. (iii) For orders of Rs 20,000 or
more and up to Rs 50,000, agents get 12% and the retailer gets 8% discount. (iv) For orders of less than Rs 20,000, agents
get 8% and the retailer gets 5% discount.These rules do not apply to the furniture items wherein a flat rate of 10% discount
is admissible to all customers irrespective of the value of the order. Design test cases using decision table testing.
R1 R2 R3 R4 R5 R6 R7 R8
C1: DGS & D T F F F F F F F
C2: Agent F T F T F T F I
Condition

C3: Retailer F F T F T F T I
Stub

C4: Order > 50,000 I T T F F F F I

C5: Order ≥ 20,000 to < 50,000 I F F T T F F I
C6: Order < 20,000 I F F F F T T I
C7: Furniture F F F F F F F T
A1: Discount of 5% X
Action Stub

A2: Discount of 8% X X
A3: Discount of 10% X X X
A4: Discount of 12% X
A5: Discount of 15% X
Decision Table based Testing
Example 2: A wholesaler has three commodities to sell and has three types of customers. Discount is given as per the
following procedure: (i) For DGS & D orders, 10% discount is given irrespective of the value of the order. (ii) For orders of
more than Rs 50,000, agents get a discount of 15% and the retailer gets a discount of 10%. (iii) For orders of Rs 20,000 or
more and up to Rs 50,000, agents get 12% and the retailer gets 8% discount. (iv) For orders of less than Rs 20,000, agents
get 8% and the retailer gets 5% discount.These rules do not apply to the furniture items wherein a flat rate of 10% discount
is admissible to all customers irrespective of the value of the order. Design test cases using decision table testing.
Expected
Test Is the Order
Type of Discount
case Product Value
Customer (Expected
ID Furniture? (Rs.)
Result)
1 DGS & D No 51,000 10%
2 Agent No 52,000 15%
3 Retailer No 53,000 10%
4 Agent No 23,000 12%
5 Retailer No 27,000 8%
6 Agent No 15,000 8%
7 Retailer No 18,000 5%
8 Agent Yes 34,000 10%
Cause-Effect Graphing based Testing
Another way to consider all valid combinations of input conditions is, to consider all valid
combinations of the equivalence classes of input conditions. If there are n different input
conditions, such that a combination is valid, then 2n test cases are expected.
Cause-effect graphing techniques help in selecting combinations of input conditions in a
systematic way, so that the number of test cases do not become unmanageably large.

The following process is used to derive the test cases.

1. Division of specification: The specification is divided into workable pieces, as cause-
effect graphing becomes complex when used on large specifications.
2. Identification of causes and effects: The next step is to identify causes and effects in
the specifications. A cause is a distinct input condition identified in the problem. It may also
be an equivalence class of input conditions. Similarly, an effect is an output condition.
3. Transformation of specification into a cause-effect graph: Based on the analysis
of the specification, it is transformed into a Boolean graph linking the causes and effects.
This is the cause-effect graph. Complete the graph by adding the constraints, if any,
between causes and effects.
4. Conversion into decision table: The cause-effect graph obtained is converted into a
limited-entry decision table by verifying state conditions in the graph. Each column in the
table represents a test case.
5. Deriving test cases: The columns in the decision table are converted into test cases.
Cause-Effect Graphing based Testing
Basic Notations for Cause-Effect Graphs:
1. Identity: if x is 1, y is 1; else y is 0.

2. Not: if x is 1, y is 0; else y is 1.

3. Or: if x or y or z is 1, A is 1; else A is 0.

4. And: if both x and y are 1, z is 1; else z is 0.

5. Exclusive: always holds that either x or y can be 1,

i.e. x and y cannot be 1 simultaneously.
Cause-Effect Graphing based Testing
Basic Notations for Cause-Effect Graphs:
6. Inclusive: at least one of x, y, and z must always be 1 (x,
y, and z cannot be 0 simultaneously).

7. One and only One: one and only one of x & y must be 1.

8. Requires: for x to be 1, y must be 1, i.e. it is impossible

for x to be 1 and y to be 0.

9. Mask: if x is 1, y is forced to 0.
Cause-Effect Graphing based Testing
Example 1:A program has been designed to determine the nature of roots of a quadratic equation.The
quadratic equation takes three input values from the range [0,100]. Design the test cases using
cause-effect graphing technique. Figure 4.6 Cause-Effect Graph
Solution:
Cause and Effects of the problem:
C1: a ≠ 0
C2: b = 0
C3: c = 0
C4: D > 0 where D is b2 – 4ac
C5: D < 0
C6: D = 0
C7: a = b = c
C8: a = c = b/2
E1: Not a quadratic equation
E2: Real roots
E3: Imaginary roots
E4: Equal roots
Cause-Effect Graphing based Testing
R1 R2 R3 R4 R5 R6 R7
Solution: C1: a ≠ 0 T T T T T T F
C2: b = 0 F I I T F F I

Condition
C3: c = 0 I F I T F F I

Stub
C4: D > 0 where D is b2 – 4ac T F F F F F I
C5: D < 0 F T F F T F I
C6: D = 0 F F T T F T I
C7: a = b = c F I F F T F I
C8: a = c = b/2 F F I F F T I
A1: Not a quadratic equation X
Action Stub

A2: Real roots X

A3: Imaginary roots X X
A4: Equal roots X X X
Cause-Effect Graphing based Testing
Test case ID a b c Expected Output
Solution: 1 1 50 50 Real Roots
2 100 50 50 Imaginary Roots
3 1 6 9 Equal
4 100 0 0 Equal
5 99 99 99 Imaginary Roots
6 50 100 50 Equal
7 0 50 30 Not a Quadratic Equation
Error Guessing
Error guessing is the preferred method used when all other methods fail. In this method,
errors or bugs can be guessed which do not fit in any of the earlier defined situations. So test
cases are generated for these special cases.
The tester uses his intuition and makes a guess about where the bug can be. The tester
does not have to use any particular testing technique. However, this capability comes with
years of experience in a particular field of testing. This is the reason that experienced
managers can easily smell out errors as compared to a novice tester.
Error guessing is an ad-hoc approach, based on intuition, experience, knowledge of project,
and bug history. Just make a list of possible errors in error-prone situations and then develop
the test cases for those situations. Thus, there is no general procedure for this technique.

For example, In the roots calculation of a quadratic equation, special cases are as follows:
What will happen when a = 0? Though, we do consider this case, there are chances that we
overlook it while testing, as it has two cases:
(i) If a = 0 then the equation is no longer quadratic.
(ii) For calculation of roots, division is by zero.
What will happen when all the inputs are negative?
What will happen when the input list is empty?