Boundary value analysis and equivalence partitioning both are test case design strategies in

black box testing.

Equivalence Partitioning:

In this method the input domain data is divided into different equivalence data classes. This
method is typically used to reduce the total number of test cases to a finite set of testable test
cases, still covering maximum requirements.

In short it is the process of taking all possible test cases and placing them into classes. One test
value is picked from each class while testing.

E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use
in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid
data.

Using equivalence partitioning method above test cases can be divided into three sets of input
data called as classes. Each test case is a representative of respective class.

So in above example we can divide our test cases into three equivalence classes of some valid
and invalid inputs.

Test cases for input box accepting numbers between 1 and 1000 using Equivalence
Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid
test case. If you select other values between 1 and 1000 then result is going to be same. So one
test case for valid input data should be sufficient.

2) Input data class with all values below lower limit. I.e. any value below 1, as an invalid input
data test case.

3) Input data with any value greater than 1000 to represent the third invalid input class.

So using equivalence partitioning you have categorized all possible test cases into three classes.
Test cases with other values from any class should give you the same result.

We have selected one representative from every input class to design our test cases. Test case
values are selected in such a way that largest number of attributes of equivalence class can be
exercised.

Equivalence partitioning uses few test cases to cover maximum requirements.

Boundary value analysis:

It’s widely recognized that input values at the extreme ends of input domain cause more errors
in the system. More application errors occur at the boundaries of the input domain. ‘Boundary
value analysis’ testing technique is used to identify errors at boundaries rather than finding
those exist in centre of the input domain.

Boundary value analysis is a next part of Equivalence partitioning for designing test cases where
test cases are selected at the edges of the equivalence classes.

Test cases for input box accepting numbers between 1 and 1000 using Boundary value
analysis:
1) Test cases with test data exactly as the input boundaries of input domain, i.e. values 1 and
1000 in our case.

2) Test data with values just below the extreme edges of input domains, i.e. values 0 and 999.

‐‐‐‐‐‐‐‐‐‐‐‐

3) Test data with values just above the extreme edges of input domain, i.e. values 2 and 1001.

Boundary value analysis is often called as a part of stress and negative testing.

Note: There is no hard‐and‐fast rule to test only one value from each equivalence class you
created for input domains. You can select multiple valid and invalid values from each
equivalence class according to your needs and previous judgments.

E.g. if you divided 1 to 1000 input values invalid data equivalence class, then you can select test
case values like: 1, 11, 100, 950 etc. Same case for other test cases having invalid data classes.

This should be a very basic and simple example to understand the Boundary value analysis and
Equivalence partitioning concept.
What is Decision Table in Software Testing
With Example?
A decision table is a good way to deal with different combination inputs with their associated
outputs and also called cause-effect table. Reason to call cause-effect table is an associated
logical diagramming technique called ’cause-effect graphing that is basically use to derive the
decision table.

Decision table testing is black box test design technique to determine the test scenarios for
complex business logic.

We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific
conditions or inputs. Although, if we have dissimilar inputs that result in different actions being
taken or secondly we have a business rule to test that there are different combination of inputs
which result in different actions. We use decision table to test these kinds of rules or logic.

Why Decision table is important?

Decision tables are very much helpful in test design technique – it helps testers to search the
effects of combinations of different inputs and other software states that must correctly
implement business rules. Also, provides a regular way of stating complex business rules, that’s
helpful for developers as well as for testers. Testing combinations can be a challenge, as the
number of combinations can often be huge. It assists in development process with developer to
do a better job. Testing with all combination might be unrealistic or unfeasible. We have to be
happy with testing just a small subset of combinations but making the option of which
combinations to test and which to leave out is also significant. If you do not have a efficient way
of selecting combinations, an arbitrary subset will be used and this may well result in an
ineffective test effort.

A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with complex
business rules. Also, used in model complicated logic.

Way to use decision tables in test designing

Firstly; get to know a suitable function or subsystem that acts according to a combination of
inputs or events. Taken system should be with fewer inputs or else combinations will become
impossible. Always better to take maximum numbers of conditions, split them into subsets and
use these subsets one at a time. After getting features that need to be combined, add them to a
table showing all combinations of “Yes” and “No” for each of the feature.
Let’s take an example of a finance application, where users pay money – monthly Repayment or
year wise (the term of loan). If user chooses both options, the system will create a negotiation
between two. So, there are two conditions of the loan amount, mention in the given below table,

TABLE 1: Blank decision table

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has
been mentioned
Terms of loan has been mentioned

Next, recognize all of the combinations in “Yes” and “No” (In Table 2). In each column of two
conditions mention “Yes” or “No”, user will get here four combinations (two to the power of the
number of things to be combined). Note, if user has three things to combine, they will have eight
combinations, with four things, there are 16, etc. Because of this, it’s always good to take small
sets of combinations at once. To keep track on combinations, give alternate “Yes” and “No” on
the bottom row, put two “Yes” and then two “No” on the row above the bottom row, etc., so the
top row will have all “Yes” and then all “No” (Apply the same principle to all such tables).

TABLE 2: Decision table – Input combination

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N
been mentioned
Terms of loan has been mentioned Y N Y N

In the next step, recognize the exact outcome for each combination (In Table 3). In this example,
user can enter one or both of the two fields. Each combination is sometimes referred to as a step.

TABLE 3: Decision table – Combinations and outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N
been mentioned
Terms of loan has been mentioned Y N Y N
Actions/Outcomes
Process loan money Y Y
Process term Y Y

At this time you didn’t think that what will happen when customer don’t enter anything in either
of the two fields. The table has shown a combination that was not given in the specification for
this example. This combination can result as an error message, so it is necessary to add another
action (In Table 4). This will flash the strength this method to find out omissions and ambiguities
in specifications.
TABLE 4: Decision table – Additional outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N
been mentioned
Terms of loan has been mentioned Y N Y N
Actions/Outcomes
Process loan money Y Y
Process term Y Y
Error message Y

We will provide you some other example that allows the customer to enter both repayment and
term. This will change the outcome of our table, this will generate an error message if both are
entered (Shown in Table 5).

TABLE 5: Decision table – Changed outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N
been mentioned
Terms of loan has been mentioned Y N Y N
Actions/Outcomes
Process loan money Y
Process term Y
Error message Y Y

The final process of this method is to write test cases to use each of the four steps in our table.

Advantage of decision table technique:

1. Any complex business flow can be easily converted into the test scenarios & test cases
using this technique.
2. Such type of table are work iteratively, means the table created at the first iteration is
used as input table for next tables. Such iteration can be carried out only if the initial table
is unsatisfactory.
3. Simple to understand and everyone can use this method design the test scenarios & test
cases.
4. It provide complete coverage of test cases which help to reduce the rework on writing test
scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition values.
This is known as its “completeness property”.
Other test cases design techniques in
Software testing:
Following black box testing techniques are used for testing the software application.

 Boundary Value Analysis (BVA)

Boundary Value Analysis is the most commonly used test case design method for black box
testing. As all we know the most of errors occurs at boundary of the input values. This is one of
the techniques used to find the error in the boundaries of input values rather than the center of the
input value range.

 Equivalence Class Partitioning

The equivalence class partition is the black box test case design technique used for writing test
cases. This approach is use to reduce huge set of possible inputs to small but equally effective
inputs. This is done by dividing inputs into the classes and gets one value from each class. Such
method is used when exhaustive testing is most wanted & to avoid the redundancy of inputs.

 State transition testing

The equivalence class partition is the black box test case design technique used for writing test
cases. In this techniques the design the test cases for the system which describes the finite
number of states. The state transition from one to other is based on the state of machine and
depending upon the what happened before the output is varies for same inputs.

 Cause-Effect Graphing Technique

The Cause-Effect Graphing Technique is a black box testing technique which captures the
relationships between specific combinations of inputs(causes) and outputs (effects). It deals with
specific cases & avoids the combinatorial explosions. The graph includes a number of
intermediate nodes linking causes and effects. Each Causes/effects are represented as nodes of a
cause effect graph.

 Error Guessing

This is totally based on previous experience and judgment of tester. Good tester are encouraged
to think conditions in which software may get the highest chances of getting errors. Such
techniques do not have any rules to decide & totally based on experience.
What is State transition testing technique?

State transition technique is a dynamic testing technique, which is used when the system is
defined in terms of a finite number of states and the transitions between the states is governed by
the rules of the system.

Or in other words, this technique is used when features of a system are represented as states
which transforms to other state. The transformations are determined by the rules of the software.
The pictorial representation can be shown as:

So here we see that an entity transitions from State 1 to State 2 because of some input
condition, which leads to an event and results to an action and finally gives the output.

To explain it with an example:

You visit an ATM and withdraw $1000. You get your cash. Now you run out of balance and
make exactly the same request of withdrawing $1000. This time ATM refuses to give you the
money because of insufficient balance. So here the transition, which caused the change in state
is the earlier withdrawal

State Transition Testing Example in Software testing:

In practical scenario, testers are normally given the state transition diagrams and we are required
to interpret it. These diagrams are either given by the Business Analysts or a stakeholder and we
use these diagrams to determine our test cases.

Let’s consider the below situation:

Software name – Manage_display_changes

Specifications – The software responds to input requests to change display mode for a time
display device.

The display mode can be set to one of the four values:

 Two corresponding to displaying either the time or date.

 The other two when altering either the time or the date.

The different states are as follows:

Change Mode (CM)

Activation of this shall cause the display mode to move between “display time (T)” and “display
date (D)”.

Reset (R)
If the display mode is set to T or D, then a “reset” shall cause the display mode to be set to “alter
time (AT)” or “alter date (AD)” modes.

Time Set (TS)

Activation of this shall cause the display mode to return to T from AT.

Date Set (DS)

Activation of this shall cause the display mode to return to D from AD.

State transition diagram is shown as:

Now, let’s move to interpret it:
Here:

1) Various states are:

 Display Time(S1),
 Change Time(S3),
 Display Date(S2) and
 Change Date (S4).

2) Various Inputs are:

 Change Mode(CM),
 Reset (R),
 Time Set(TS),
 Date Set(DS).

3) Various Outputs are:

 Alter Time(AT),
 Display Time(T),
 Display Date(D),
 Alter Date (AD).

4) Changed States are:

 Display Time(S1),
 Change Time (S3),
 Display Date (S2) and
 Change Date (S4).
Step 1:

Write all the start state. For this, take one state at a time and see how many arrows are coming
out from it.

 For State S1, there are two arrows coming out of it. One arrow is going to state S3 and other
arrow is going to state S2.
 For State S2 – There are 2 arrows. One is going to State S1 and other going to S4
 For State S3 – Only 1 arrow is coming out of it, going to state S1
 For State S4 – Only 1 arrow is coming out of it, going to state S2

Let’s put this into our table:

Since, for state S1 and S2 there are two arrows coming out, we have written it twice.

Step -2:

For each state, write down their final state.

 For state S1 – The final states are S2 and S3

 For State S2 – The final states are S1 and S4
 For State S3 – Final state is S1
 For State S4 – Final State is S2

Put this in the table as output / resultant state.

------------

Step 3:

For each start state and its corresponding finish state, write down the input and output conditions
– For state S1 to go to state S2, the input is Change Mode (CM) and output is Display Date(D)
shown below:
In a similar way, write down the Input conditions and its output for all the states as follows:

Step 4:

Now add the test case ID for each tests shown below:

Now let’s convert it to a formal test cases:

(Click image to enlarge)

In this way all the remaining test cases can be derived. I assume the other attributes of the test
cases like preconditions, severity, priority, environment, build etc. are also included in the test
case.

Conclusion:

Summarizing the steps once again:

1. Identify the initial states and their final state based on the lines/arrows that are coming out of
the initial state
2. For each initial state, find out the input condition and the output result
3. Mark each set as a separate test case.

State Transition testing is a unique test approach for testing complex applications, which
would increase test execution productivity without compromising on test coverage.

Cause and effect graph is a dynamic test case writing technique. Here causes are the input
conditions and effects are the results of those input conditions.

Cause-Effect Graphing is a technique which starts with set of requirements and determines the
minimum possible test cases for maximum test coverage which reduces test execution time and
ultimately cost.

The goal is to reduce the total number of test cases still achieving the desired application quality
by covering the necessary test cases for maximum coverage.

But at the same time obviously there are some downsides of using this test case writing
technique. It takes time to model all your requirements into this cause-effect graph before writing
test cases.

The Cause-Effect graph technique restates the requirements specification in terms of logical
relationship between the input and output conditions. Since it is logical, it is obvious to use
Boolean operators like AND, OR and NOT.

Notations we are going to use:

Now let’s try to implement this technique with some example.

1. Draw a cause and effect graph based on a requirement/situation

2. Cause and Effect graph is given, draw a decision table based on it to draw the test case.
Let’s see both of them one by one.

Let’s draw a cause and effect graph based on a situation

Situation:

The “Print message” is software that read two characters and, depending of their values,
messages must be printed.

 The first character must be an “A” or a “B”.

 The second character must be a digit.
 If the first character is an “A” or “B” and the second character is a digit, the file must be
updated.
 If the first character is incorrect (not an “A” or “B”), the message X must be printed.
 If the second character is incorrect (not a digit), the message Y must be printed.

Solution:

The causes for this situation are:

C1 – First character is A
C2 – First character is B
C3 – Second character is a digit

The effects (results) for this situation are

E1 – Update the file
E2 – Print message “X”
E3 – Print message “Y”

LET’S START!!

First draw the causes and effects as shown below:

Key – Always go from effect to cause (left to right). That means, to get effect “E” ,what causes
should be true.

In this example, let’s start with Effect E1.

Effect E1 is to update the file. The file is updated when

– First character is “A” and second character is a digit
– First character is “B” and second character is a digit
– First character can either be “A” or “B” and cannot be both.

Now let’s put these 3 points in symbolic form:

For E1 to be true – following are the causes:

– C1 and C3 should be true
– C2 and C3 should be true
– C1 and C2 cannot be true together. This means C1 and C2 ae mutually exclusive.

Now let’s draw this:

So as per the above diagram, for E1 to be true the condition is
(C1 C2) C3

The circle in the middle is just an interpretation of the middle point to make the graph less
messy.
There is a third condition where C1 and C2 are mutually exclusive. So the final graph for effect
E1 to be true is shown below:

Lets move to Effect E2:

E2 states to print message “X”. Message X will be printed when First character is neither A nor
B.
Which means Effect E2 will hold true when either C1 OR C2 is invalid. So the graph for Effect
E2 is shown as (In blue line)

For Effect E3.

E3 states to print message “Y”. Message Y will be printed when Second character is incorrect.
Which means Effect E3 will hold true when C3 is invalid. So the graph for Effect E3 is shown as
(In Green line)

------------
This completes the Cause and Effect graph for the above situation.

Now let’s move to draw the Decision table based on the above graph.

Writing Decision table based on Cause and Effect graph

First write down the Causes and Effects in a single column shown below

Key is the same. Go from bottom to top which means traverse from effect to cause.

Start with Effect E1. For E1 to be true, the condition is: (C1 C2) C3 .
Here we are representing True as 1 and False as 0

First put Effect E1 as True in the next column as

Now for E1 to be “1” (true), we have the below two conditions –

C1 AND C3 will be true
C2 AND C3 will be true

For E2 to be True, either C1 or C2 has to be false shown as

For E3 to be true, C3 should be false.

So it’s done. Let’s complete the graph by adding 0 in the blank column and including the test
case identifier.

Writing Test cases from the decision table

I am writing a sample test case for test case 1 (TC1) and Test Case 2 (TC2).

In a similar fashion, you can create other test cases.

(A test case contains many other attributes like preconditions, test data, severity, priority, build,
version, release, environment etc. I assume all these attributes to be included when you write the
test cases in actual situation)

Conclusion

Summarizing the steps once again:

1. Draw the circles for Causes and Graphs

2. Start from effects and move towards the cause.
3. Look for mutually exclusive causes.

This finishes the Cause and Effect graph dynamic test case writing technique. We have seen how
to draw the graph and how to draw the decision table based on it. The final step of writing test
cases based on decision table is comparatively easy.