Firstly Let Us Understand The Meaning of Black Box Testing

Introduction to Black Box Testing Techniques
Firstly let us understand the meaning of Black Box Testing.
The term 'Black Box' refers to the software, which is treated as a black box. By treating it as a black box, we
mean that the system or source code is not checked at all. It is done from customer's viewpoint. The test
engineer engaged in black box testing only knows the set of inputs and expected outputs and is unaware of how
those inputs are transformed into outputs by the software.
Types of Black Box Testing Techniques: Following techniques are used for performing black box testing
1) Boundary Value Analysis (BVA)
2) Equivalence Class Testing
3) Decision Table based testing
4) Cause-Effect Graphing Technique
1) Boundary Value Analysis (BVA):
This testing technique believes and extends the concept that the density of defect is more towards the
boundaries. This is done to the following reasons
a) Usually the programmers are not able to decide whether they have to use <= operator or < operator when
trying to make comparisons.
b) Different terminating conditions of For-loops, While loops and Repeat loops may cause defects to move
around the boundary conditions.
c) The requirements themselves may not be clearly understood, especially around the boundaries, thus causing
even the correctly coded program to not perform the correct way.
2) Equivalence Class Testing:

The use of equivalence classes as the basis for functional testing is appropriate in situations like
a) When exhaustive testing is desired.
b) When there is a strong need to avoid redundancy.
The above are not handled by BVA technique as we can see massive redundancy in the tables of test cases. In
this technique, the input and the output domain is divided into a finite number of equivalence classes.
3) Decision Table Based Testing:
Decision tables are a precise and compact way to model complicated logic. Out of all the functional testing
methods, the ones based on decision tables are the most rigorous due to the reason that the decision tables
enforce logical rigour.
Decision tables are ideal for describing situations in which a number of combinations of actions are taken under
varying sets of conditions.

4) Cause-Effect Graphing Technique:
This is basically a hardware testing technique adapted to software testing. It considers only the desired external
behaviour of a system. This is a testing technique that aids in selecting test cases that logically relate Causes
(inputs) to Effects (outputs) to produce test cases.
A “Cause” represents a distinct input condition that brings about an internal change in the system. An “Effect”
represents an output condition, a system transformation or a state resulting from a combination of causes.
Boundary Value Analysis (BVA) – A Black Box Testing Technique
This Black Box testing technique believes and extends the concept that the density of defect is more towards the
boundaries. This is done due to the following reasons

a) Usually the programmers are not able to decide whether they have to use <= operator or < operator when
trying to make comparisons.

b) Different terminating conditions of For-loops, While loops and Repeat loops may cause defects to move around the boundary
conditions.

c) The requirements themselves may not be clearly understood, especially around the boundaries, thus causing
even the correctly coded program to not perform the correct way.

The basic idea of BVA is to use input variable values at their minimum, just above the minimum, a nominal value,
just below their maximum and at their maximum. Meaning thereby (min, min+, nom, max-, max), as shown in the
fiollowing figure.
BVA is based upon a critical assumption that is known as “Single fault assumption theory”. According to this assumption, we derive
the test cases on the basis of the fact that failures are not due to simultaneous occurrence of two (or more) faults. So, we derive test
cases by holding the values of all but one variable at their nominal values and allowing that variable assume its extreme values.
If we have a function of n-variables, we hold all but one at the nominal values and let the remaining variable
assume the min, min+, nom, max-and max values, repeating this for each variable. Thus, for a function of n
variables, BVA yields (4n + 1) test cases.
Limitations of BVA:
1) Boolean and logical variables present a problem for Boundary Value Analysis.
2) BVA assumes the variables to be truly independent which is not always possible.
3) BVA test cases have been found to be rudimentary because they are obtained with very little insight and
imagination.
Robustness Testing:
Robustness Testing is another variant of BVA
In BVA, we remain within the legitimate boundary of our range i.e. for testing we consider values like (min, min+,
nom, max-, max) whereas in Robustness testing, we try to cross these legitimate boundaries as well.
Thus for testing here we consider the values like (min-, min, min+, nom, max-, max, max+)
Again, with robustness testing, we can focus on exception handling. With strongly typed languages, robustness
testing may be very awkward. For example, in PASCAL, if a variable is defined to be within a certain range, values
outside that range result in run-time errors thereby aborting the normal execution.
For a program with n-variables, robustness testing will yield (6n + 1) test-cases. Thus we can draw the following
Robustness Test Cases graph.
Each dot represents a test value at which the program is to be tested. In Robustness testing, we cross the
legitimate boundaries of input domain. In the above graph, we show this by dots that are outside the range [a, b]
of variable x1. Similarly, for variable x2, we have crossed its legitimate boundary of [c, d] of variable x2.

This type of testing is quite common in electric and electronic circuits. Furthermore, this type of testing also works
on 'single fault assumption theory'.

Worst Case Testing:

If we reject our basic assumption of single fault assumption theory and focus on what happens when we reject this
theory-it simply means that we want to see that what happens when more than one variable has an extreme
value. In electronic circuit analysis, this is called as "worst-case analysis". We use this idea here to generate worst-
case test cases.

For each variable, we start with the five-element set that contains the min, min+, nom, max-, and max values. We
then take the Cartesian product of these sets to generate test cases. This is shown in following graph
For a program with n-variables, 5n test cases are generated.
Guidelines for BVA:

1) The normal versus robust values and the single fault versus the multiple-fault assumption theory result in
better ttjung. These methods can be applied to both input and output domain of any program.

2) Robustness testing is a good choice for testing internal variables.

3) We must bear in mind that we can create extreme boundary results from non-extreme input values.
Equivalence Class Testing - Black Box Software Testing Techniques
The use of equivalence classes as the basis for functional testing and is appropriate in situations like

a) When exhaustive testing is desired.

b) When there is a strong need to avoid redundancy.

The above are not handled by BVA technique as we can see massive redundancy in the tables of test cases. In this
technique, the input and the output domain is divided into a finite number of equivalence classes.
Then, we select one representative of each class and test our program against it. It is assumed by the tester that if
one representative from a class is able to detect error then why should he consider other cases. Furthermore, if
this single representative test case did not detect any error then we assume that no other test case of this class
can detect error. In this method we consider both valid and invalid input domains. The system is still treated as a
black-box meaning that we are not bothered about its internal logic.

The idea of equivalence class testing is to identify test cases by using one element from each equivalence class. If
the equivalence classes are chosen wisely, the potential redundancy among test cases can be reduced.

Types of equivalence class testing:

Following four types of equivalence class testing are presented here

1) Weak Normal Equivalence Class Testing.

2) Strong Normal Equivalence Class Testing.

3) Weak Robust Equivalence Class Testing.

4) Strong Robust Equivalence Class Testing.

1) Weak Normal Equivalence Class Testing:
The word 'weak' means 'single fault assumption'. This type of testing is accomplished by using one variable from
each equivalence class in a test case. We would, thus, end up with the weak equivalence class test cases as shown
in the following figure.
Each dot in above graph indicates a test data. From each class we have one dot meaning that there is one
representative element of each test case. In fact, we will have, always, the same number of weak equivalence
class test cases as the classes in the partition.

2) Strong Normal Equivalence Class Testing:
This type of testing is based on the multiple fault assumption theory. So, now we need test cases from each
element of the Cartesian product of the equivalence classes, as shown in the following figure.
Just like we have truth tables in digital logic, we have similarities between these truth tables and our pattern of
test cases. The Cartesian product guarantees that we have a notion of "completeness" in following two ways

a) We cover all equivalence classes.

b) We have one of each possible combination of inputs.

3) Weak Robust Equivalence Class Testing:
The name for this form of testing is counter intuitive and oxymoronic. The word' weak' means single fault
assumption theory and the word 'Robust' refers to invalid values. The test cases resulting from this strategy are
shown in the following figure.
Following two problems occur with robust equivalence testing.

a) Very often the specification does not define what the expected output for an invalid test case should be. Thus,
testers spend a lot of time defining expected outputs for these cases.

b) Strongly typed languages like Pascal, Ada, eliminate the need for the consideration of invalid inputs. Traditional
equivalence testing is a product of the time when languages such as FORTRAN, C and COBOL were dominant. Thus
this type of error was quite common.

4) Strong Robust Equivalence Class Testing:
This form of equivalence class testing is neither counter intuitive nor oxymoronic, but is just redundant. As
explained earlier also, 'robust' means consideration of invalid values and the 'strong' means multiple fault
assumption. We obtain the test cases from each element of the Cartesian product of all the equivalence classes as
shown in the following figure.
We find here that we have 8 robust (invalid) test cases and 12 strong or valid inputs. Each one is represented with
a dot. So, totally we have 20 test cases (represented as 20 dots) using this technique.

Guidelines for Equivalence Class Testing:

The following guidelines are helpful for equivalence class testing

1) The weak forms of equivalence class testing (normal or robust) are not as comprehensive as the corresponding
strong forms.

2) If the implementation language is strongly typed and invalid values cause run-time errors then there is no point
in using the robust form.

3) If error conditions are a high priority, the robust forms are appropriate.

4) Equivalence class testing is approximate when input data is defined in terms of intervals and sets of discrete
values. This is certainly the case when system malfunctions can occur for out-of-limit variable values.

5) Equivalence class testing is strengthened by a hybrid approach with boundary value testing (BVA).

6) Equivalence class testing is used when the program function is complex. In such cases, the complexity of the
function can help identify useful equivalence classes.

7) Strong equivalence class testing makes a presumption that the variables are independent and the corresponding
multiplication of test cases raises issues of redundancy. If any dependencies occur, they will often generate "error"
test cases.

8) Several tries may be needed before the "right" equivalence relation is established.

9) The difference between the strong and weak forms of equivalence class testing is helpful in the distinction
between progression and regression testing.
Decision Table Based Testing - Black Box Software Testing Technique
Of all the functional testing methods, those based on decision tables are the most rigorous because decision tables
enforce logical rigour.
What are Decision Tables?
Decision tables are precise and compact way to model complicated logic. They are ideal for describing situations in
which a number of combinations of actions are taken under varying sets of conditions.
It is another popular black box testing. A decision table has following four portions
(a) Stub portion

(b) Entry portion
(c) Condition portion, and
(d) Action portion
Structure of decision table: Please refer following decision table
A column in the entry portion is known as a rule. Rules indicate which actions are taken for the conditional
circumstances indicated in the condition portion of the rule. Decision tables in which all conditions are binary are
known as “Limited entry decision tables”. If conditions are allowed to have several values, the resulting tables
are known as “Eextended entry decision tables”.
Following steps are used to identify the test cases with decision tables:

Step – 1: For a module, identify input conditions (causes) and action (effect).
Step – 2: Develop a cause-effect graph.
Step – 3: Transform this cause-effect graph, so obtained in step 2 to a decision table.
Step – 4: Convert decision table rules to test cases.
Each column of the decision table represents a test case. That is,

Number of Test Cases = Number of Rules

For a limited entry decision tables, if n conditions exist, there must be 2 n rules.
What are the Advantages of Decision Tables:

1. This type of testing also works iteratively. The table that is drawn in the first iteration, acts as a stepping stone
to derive new decision table(s), if the initial table is unsatisfactory.

2. These tables guranatee that we consider every possible combination of condition values. This is known as its
"completeness property". This property promises a form of complete testing as compared to other techniques.

3. Decision tables are declarative. There is no particular order for conditions and actions to occur.
What are the Disadvantages of Decision Tables:
Decision tables do not scale up well. We need to "factor" large tables into smaller ones to remove redundancy.

Applications of Decision Tables:

This technique is useful for applications characterized by any of the following

(a) Prominent if-then-else logic.

(b) Logical relationships among input variables.

(c) Calculations involving subsets of the input variables.

(d) Cause-and-effect relationships between inputs and outputs.

(e) High cyclomatic complexity.

Technique of using Decision Table:
To identify test cases with decision tables, we interpret conditions as inputs and actions as output. The rules are
interpreted as test cases. Because the decision table can mechanically be forced to be complete, we know we have
a comprehensive set of test cases.
Guidelines for Decision Table Based Testing:

The following guidelines have been formulated after studying above examples

1) This technique works well where lot of decision making takes place such as the triangle problem and Next date
problem.

2) The decision table technique is indicated for applications characterized by any of the following > Prominent if-
then-else logic.

# Logical relationships among input variables.

# Calculations involving subsets of the input variables.

# Cause-and-effect relationships between inputs and outputs.
# High cyclomatic complexity.

3) Decision tables do not scale up well. We need to 'factor' large tables into smaller ones to remove redundancy.

4) It works iteratively meaning that the table drawn in the first iteration, acts as a stepping stone to design new
decision tables, if the initial table is unsatisfactory.
Cause-Effect Graphing - Black Box Software Testing Technique
This is basically a hardware testing technique adapted to software testing. It considers only the desired external
behaviour of a system. This is a testing technique that aids in selecting test cases that logically relate Causes
(inputs) to Effects (outputs) to produce test cases.

A “Cause” represents a distinct input condition that brings about an internal change in the system. An “Effect”
represents an output condition, a system transformation or a state resulting from a combination of causes.

According to Myer Cause & Effect Graphing is done through the following steps:

Step – 1: For a module, identify the input conditions (causes) and actions (effect).

Step – 2: Develop a cause-effect graph.

Step – 3: Transform cause-effect graph into a decision table.

Step – 4: Convert decision table rules to test cases. Each column of the decision table represents a test case.

Basic symbols used in Cause-effect graphs are as under:
Consider each node as having the value 0 or 1 where 0 represents the 'absent state' and 1 represents
the'present state'. Then the identity function states that if c1 is 1, e1 is 1 or we can say if c0 is 0, e0 is 0.

The NOT function states that if C1 is 1, e1 is 0 and vice-versa. Similarly, OR function states that if C1 or C2 or
C3 is 1, e1 is 1 else e1 is 0. The AND function states that if both C, and C2 are 1, e1 is 1; else e1 is 0. The AND
and OR functions are allowed to have any number of inputs.

The concept of designing test cases can be illustrated through the example of the “Triangle Problem” covered
under White Box Testing “Tutorial – 5: Estimation of Complexity Measure V(G) : For a Triangle”.

Going by the Myer methodology, test cases can be designed for the triangle problem in the following
way:

Step – 1: First of all we need to identify the causes and its effects.

The causes designated by letter “C” are as under

C1 : Side “x” is less than sum of “y” and “z”
C2 : Side “y” is less than sum of “x” and “z”
C3 : Side “z” is less then sum of “x” and “y”
C4 : Side “x” is equal to side “y”
C5 : Side “x” is equal to side “z”
C6 : Side “y” is equal to side “z”

The effects designated by letter “e” are as under

e1 : Not a triangle
e2 : Scalene triangle
e3 : Isosceles triangle.
e4 : Equilateral triangle
e5 : Impossible

Step – 2: Draw the following cause-effect graph
Step – 3: Transform cause-effect graph into the following decision table
Step 4. Since there are 11 rules, we get following 11 test cases
Test x y z Expected
Case Output
1 4 1 2 Not a triangle
4 5 5 5 Equilateral
5 ? ? ? Impossible
6 ? ? ? Impossible
7 2 2 3 Isosceles
8 ? ? ? Impossible
9 2 3 2 Isosceles
10 3 2 2 Isosceles
11 3 4 5 Scalene
Guidelines for Cause-Effect Functional Testing Technique:

1) If the variables refer to physical quantities, domain testing and equivalence class testing are indicated.

2) If the variables are independent, domain testing and equivalence class testing are indicated.

3) If the variables are dependent, decision table testing is indicated.

4) If the single-fault assumption is warranted, boundary value analysis (BVA) and robustness testing are
indicated.

5) If the multiple-fault assumption is warranted, worst-case testing, robust worst-case testing and decision table
testing are identical.

6) If the program contains significant exception handling, robustness testing and decision table testing are
indicated.

7) If the variables refer to logical quantities, equivalence class testing and decision table testing are indicated.
Comparison among various Black Box or Functional Software Testing Techniques
Testing Effort
The functional methods vary both in terms of the number of test cases generated and the effort to develop
these test cases. To compare the three techniques, namely, boundary value analysis (BVA), equivalence class
partitioning and decision table based technique let us focus our attention on the following graph.
The domain-based techniques have no recognition of data or logical dependencies. They are very mechanical in
the way they generate test cases. Because of this, they are also easy to automate. The techniques like
equivalence class testing focus on data dependencies and thus we need to demonstrate our skill. The thinking
goes into the identification of the equivalence classes and after that, the process is mechanical. It may be noted
from the graph, that the decision table based technique is most sophisticated because it requires the tester to
consider both data and logical dependencies. It may be seen that once we get a good and healthy set of
conditions, the resulting test cases are complete and minimal.
Now, consider another graph to show the effort required to identify the test cases versus its sophistication.
Thus we can say that the effort required to identify test cases is lowest in BVA and highest in decision tables.
The end result is a trade-off between the test case effort identification and test case execution effort. If we shift
our effort toward more sophisticated testing methods, we reduce our test execution time. This is very important
as tests are usually executed several times. It may be noted that, judging testing quality in terms of the sheer
number of test cases has drawbacks similar to judging programming productivity in terms of lines of code.
Effect of various Testing Stretegies on Testing Efficiency:

It is evident from all the abobve mentioned functional testing strategies that either the functionality is untested
or the test cases are redundant. So, gaps do occur in functional test cases and these gaps are reduced by using
more sophisticated techniques.
We can develop various ratios of total number of test cases generated by method-A to those generated by
method-B or even ratios on a test case basis. This is more difficult but sometimes the management may
demand numbers even when they have little real meaning. When we see several test cases with the same
purpose, sense redundancy, detecting the gaps is quite difficult. If we use only functional testing, the best we
can do is to compare the test cases that result from two methods. In general, the more sophisticated method
will help us recognize gaps but nothing is guaranted.
How to measure Testing Effectiveness of these Testing Techniques:

The easiest choice is

1) Be Dogmatic: We can select a method, use it to generate test cases and then run the test cases. We can improve on this by
not being dogmatic and allowing the tester to choose the most appropriate method. We can gain another incremental
improvement by devising appropriate hybrid methods.

2) The second choice can be the structural testing techniques for the test effectiveness.
It may be noted that the best interpretation for testing effectiveness is most difficult. We would like to know
how effective a set of test cases is for finding faults present in a program. This is problematic due to the
following two reasons.

1) It presumes that we are aware of the faults in a program.

2) Proving that a program is fault-free is equivalent to the famous halting problem of computer science, which is
known to be impossible.

Then What is the Best Solution ?

The best solution is to work backward from fault types. Given a particular kind of fault, we can choose testing
methods (functional and structural) that are likely to reveal faults of that type. If we couple this with knowledge
of the most likely kinds of faults, we end up with a pragamatic approach to testing effectiveness. This is
improved if we track the kinds of faults and their frequencies in the software we develop.
Key Guidelines for the Functional Testing

1) If the variables refer to physical quantities then domain testing and equivalence class testing should be used.
2) If the variables are independent then domain testing and equivalence class testing should be used.
3) If the variables are dependent, decision table testing should be practiced.

4) If the single-fault assumption is warranted then BVA and robustness testing should be used.

5) If the multiple-fault assumption is warranted then worst case testing, robust worst case testing and decision
table based testing should be practiced.

6) If the program has significant exception handling, robustness testing and decision table based testing are
identical.

7) If the variable refers to logical quantities, equivalence class testing and decision table testing should be
practiced.
Various Scenarios & appropriate Black Box Testing Techniques
A summary on various scenarios under which different Black Box testing techniques will be useful are as
under:
Sr. Type of Test Scenario Appropriate Black
Box Testing
Technique
1 Output values dictated by Decision tables.
certain conditions
depending upon values of
input variables.
2 Input values in ranges, with Boundary Value
each range showing a Analysis (BVA).
particular functionality.
3 Input values divided into Equivalence
classes. partitioning.
4 Checking for expected and Positive and negative
unexpected input values. testing.
5 Workflows, process flows or Graph based testing.
language processors.
6 To ensure that Requirements based
requirements are tested testing.
and met properly.
7 To test the domain Domain testing.
expertise rather than
product specification.
8 To ensure that the Documentation
documentation is consistent testing.
with the product.
Kiviat Charts the Best Black Box Graphical Tool for Problem Identifica tion
Kiviat charts are versatile graphical display tool which presents different metrics against maximum & minimum
benchmarks.
Kiviat chart consists of radial lines representing a particular metric. Every metric is drawn to a suitable scale;
wherein maximum & minimum values are represented by outer & inner concentric circles.
In the charts shown below the outer circle is the maximum threshold and the band is the minimum threshold. The
band between the two circles is the acceptable range.
A Sample of Kiviat Charts for Development Code Metrics for a web application is presented below:
All metrics falling within the acceptable limits are represented by the following chart.
Good Kiviat chart showing all metrics within limits:

On the contrary, the following bad Kiviat chart indicates all but one (cLOC) of the metrics outside the high limit:
Advantages of Kiviat Charts:
1) Kiviat Charts are helpful in providing an effective visual or graphical representation of problems or concepts
quite complex in nature.
2) Kiviat charts are helpful in providing a sharp attention to the vulnerable areas needing a quick focus.
3) Various problems or concepts can be presented graphically by customizing the scale of the Kiviat charts to suit
the individual needs.
Need of the Concept of Balance in Kiviat Charts:
Let us consider a problem having multiple dimensions like the following:
1) Computer : having processor, printer, disks, CDROM, modem etc.
2) Software
3) Personnel
All the above when put together, create multiple dimensions and hence the concept of having a balance is needed.
Method of creating Kiviat Charts:
Kiviat charts are usually drawn by using the following steps:
Step - 1: Choose factors to be measured.
Step - 2: Define factors so that for half the optimum utilization is 1 and for half 0.
Step - 3: Mark of the factors around the chart so that axes with an optimum of 0 alternate with those with an
optimum of 1.
Step - 4: Mark of the values on the factor axes.
Step - 5: Join the marks to form a "star'.
Step - 6: Evaluate the result.
We shall now consider four different cases to draw Kiviat Charts.
Case 1: Kiviat charts - A perfectly balanced system:
Consider a sample data given below.
A = 0.8
B = 0.2
C = 0.8
D = 0.2
E = 0.8
F = 0.2
G = 0.8
H = 0.2
It's Kiviat chart is also shown below
Case 2: Kiviat charts - A well balanced system:
Consider a sample data for a well-balanced system as given below.
A = 0.9
B = 0.15
C = 0.85
D = 0.2
E = 0.9
F = 0.1
G = 0.8
H = 0.2

Case 3: Kiviat charts - A poorly balanced system:
Consider a sample data for a poorly-balanced system as given below.
A = 0.4
B = 0.6
C = 0.5
D = 0.4
E = 0.7
F = 0.4
G = 0.6
H = 0.5

Case 4: Kiviat charts - A perfectly balanced system:
Consider a sample data for a perfectly-balanced system as given below.
A=1
B=0
C=1
D=0
E=1
F=0
G=1
H=0

Tutorial -1: To Generate BVA Test Cases – For Tax Calculation Problem
Boundary Value Analysis is a data selection technique in which test data is selected from the "boundaries" of the
input or output domain classes, data structures and procedure parameters. Selection mainly include the actual
minimum and maximum boundary values, with a tolerance of (+ 1 or - 1) on the maximum and the minimum
values.
Boundary Value Analysis is similar to Equivalence Partitioning, however it focuses on "Boundary or Corner Cases".
Although according to Equivalence Partitioning definition, testing of one value from a particular class is equivalent
to doing the testing of any other value from that particular class; since boundaries are more prone to errors, hence
boundaries of equivalent classes need to be given more close consideration.
Following type of test cases utilizing boundary value analysis are considered for various range of
values.
a) Two valid test cases covering extreme ends

b) Two invalid test cases immediately across the range limits
Let us take an example program where we consider "Pay" as an input having values 12000 to 35000 in the valid
range. The program calculates the corresponding tax with following assumptions:
1) Pay up to Rs. 15000 – Tax is Zero

2) Pay between 15001 and 25000 – Tax is 18 % of Pay
3) Pay above 25000 – Tax is 20% of Pay
Here the valid input domain can be divided into three valid equivalent classes like:
Class c1 : Values in the range 12000 to 15000

Class c2: Values in the range 15001 to 25000
Class c3: Values more than 25000
Test cases utilizing valid equivalence classes having values in falling within the range of 12000 to 15000 of Pay
shall be
While observing the "Observed Output" column, Desired Outputs are always found to be different for any set of two
successive inputs. Hence it is necessary to carryout the testing with the help of boundary value analysis approach
by maintaining such difference. Similar approach is applied to verify the output boundaries as well.
Few other illustrations of test cases designed with boundary value analysis approach are:
a) Testing of a compiler using an empty source code

b) Testing of trigonometric functions as TAN having values close to p/2
c) Testing of a function involving deletion of a record from a particular empty data file or a data file having just a
single record.
Thus summarizing, Boundary Value Analysis is an efficient approach of designing the test cases, which can discover
majority of most common errors getting introduced during the programming.
Tutorial -2: To Generate BVA Test Cases – For the Triangle Problem
Before we generate the test cases, firstly we need to define the problem domain as described below.
Problem Domain: "The triangle program accepts three integers, a, b and c as input. These are taken to be the sides of a triangle.
The integers a, b and c must satisfy the following conditions
C1: 1 ≤ a ≤ 200
C2: 1 ≤ b ≤ 200
C3: 1 ≤ c ≤ 200
C4: a < b+c
C5: b < a+c
C6: c < a+b
The output of the program may be either of: Equilateral Triangle, Isosceles Triangle, Scalene or "Not a Traingle".
Objective of this Tutorial: How to Generate BVA Test Cases for this problem?
We know that our range is [1, 200] where 1 is the lower bound and 200 being the upper bound.
Also, we find that this program has three inputs like a, b and c.
Hence for our case number of inputs or n = 3
Since BVA yields (4n + 1) test cases according to single fault assumption theory, hence we can say that the total number of test
cases will be (4*3+1)=12+1=13.
Now we can draw the following Table indicating all the 13 test-cases.
Test Side Side Side Expected Output

Case ID "a" "b" "c"
1 100 100 1 Isosceles Triangle
3 100 100 100 Equilateral Triangle
5 100 100 200 Not a Triangle
It may be noted that as explained above that we can have 13 test cases (4n + 1) for this problem. But instead of 13, now we have
15 test cases.
Moreover we can see that the test cases vide ID number 8 and 13 are redundant. Hence we can ignore them. However, we do not
ignore test case ID number 3, as we must consider at least one test case out of these three. Thus it is evident that it is a mechanical
activity.
Hence we can say that these 13 test cases are sufficient to test this program using BVA technique.
Tutorial -3: To Generate BVA Test Cases – For the Next Date Function
Before we generate the test cases for the Next Date Function problem, firstly we need to define the problem
domain as described below.
Problem Domain: "Next Date" is a function consisting of three variables like: month, date and year. It returns the
date of next day as output. It reads current date as input date.
The conditions are
C1: 1 ≤ month ≤ 12
C2: 1 ≤ day ≤ 31
C3: 1900 ≤ year ≤ 2025.
If any one condition out of C1, C2 or C3 fails, then this function produces an output "value of month not in the
range 1...12".
Since many combinations of dates can exist, hence we can simply displays one message for this function : "Invalid
Input Date".
Complexities in Next Date Function
A very common and popular problem occurs if the year is a leap year. We have taken into consideration that there
are 31 days in a month. But what happens if a month has 30 days or even 29 or 28 days ?
A year is called as a leap year if it is divisible by 4, unless it is a century year. Century years are leap years only if
they are multiples of 400. So, 1992, 1996 and 2000 are leap years while 1900 is not a leap year.
Furthermore, in this Next Date problem we find examples of Zipf's law also, which states that "80% of the
activity occurs in 20% of the space". Thus in this case also, much of the source-code of Next Date function is
devoted to the leap year considerations.
The Next Date program takes date as input and checks it for validity. If it is valid, it returns the next date as its
output.
Here we have three inputs for the program, hence n = 3.
Since BVA yields (4n + 1) test cases according to single fault assumption theory, hence we can say that the total
number of test cases will be (4*3+1)=12+1=13.
The boundary value test cases are
Test Month Day Year Expected Output

Case ID (mm) (dd) (yyyy)
1 6 15 1900 16 June, 1900
2 6 15 1901 16 June, 1901
3 6 15 1962 16 June, 1962
4 6 15 2024 16 June, 2024
5 6 15 2025 16 June, 2025
6 6 1 1962 2 June, 1962
7 6 2 1962 1 June, 1962
8 6 30 1962 1 July 1962
9 6 31 1962 Invalid Date as June

has 30 Days
10 1 15 1962 16 January, 1962
11 2 15 1962 16 February, 1962
12 11 15 1962 16 November, 1962
13 12 15 1962 16 December, 1962
This is how we can apply BVA technique to create test cases for our Next Date Problem.
Tutorial -4: To Generate BVA Test Cases – For the Salesman Commision Calculation Program
Before we generate the test cases for the sales commission calculation program, firstly we need to define the
problem domain as described below.
Problem Domain: "A desert cooler sales person sold cooler fans, pumps and bodies that were made by a cooler
maker. Fans cost $45, pumps cost $30 and bodies cost $25.
The salesperson had to sell at least one complete cooler per month, and the production limits were such that the
most the sales person could sell in a month was 70 fans, 80 pumps and 90 bodies. The sales person used to send
the details of sold items to the cooler maker. The cooler maker then computed the sales person's commission as
follows:
1) 10% on sales upto and including $1000.
2) 15% of the next $800.
3) And 20% on any sales in excess of $1800.
The commission program produced a monthly sales report that gave the total number of fans, pumps and bodies
sold, the sales person's total dollar sales and finally, the commission."
Here we have three inputs for the program, hence n = 3.
Since BVA yields (4n + 1) test cases according to single fault assumption theory, hence we can say that the total
number of test cases will be (4*3+1)=12+1=13.
The boundary value test cases are
We can see that the monthly sales are limited by the following consideration:
1 ≤ fans ≤ 70
1 ≤ pumps ≤ 80
1 ≤ bodies ≤ 90
Test Case Fans Pumps Bodies Expected Output of

ID Sales
1 35 40 1 2800
2 35 40 2 2825
3 35 40 45 3900
4 35 40 89 5000
5 35 40 90 5025
6 35 1 45 2730
7 35 2 45 2760
8 35 40 45 3900
9 35 79 45 5070
10 35 80 45 5100
11 1 40 45 2370
12 2 40 45 2415
13 35 40 45 3900
14 69 40 45 5430
15 70 40 45 5475
Here we can see that out of 15 test cases, two are redundent. Hence 13 test cases are sufficient to test this
program.
Tutorial -6: To Generate Equivalence Class Test Cases – For the Triangle Problem
The triangle program takes three integers, a, b and c as input. These are taken to be the sides of the triangle.
The output of the program can be either of: Equilateral Triangle, Isosceles Triangle, Scalene or "Not a Triangle".
We can use these to identify output (range) equivalence classes as under:
01 = { : the triangle is equilateral}
02 = { : the triangle is isosceles}
03 = { : the triangle is scalene}
04 = { : sides a, b and c do not form a triangle}
Objective of this Tutorial: To apply the four techniques of equivalence class partitioning one by one &
generate appropriate test cases?
1) Weak Normal Equivalence Class: The four weak normal equivalence class test cases can be defined as under
Test Case Side Side Side Expected Output

ID "a" "b" "c"
WN1 5 5 5 Equilateral Triangle
WN2 2 2 3 Isosceles Triangle

WN3 3 4 5 Scalene Triangle
WN4 4 1 2 Not a Triangle
2) Strong Normal Equivalence Class: Since no valid subintervals of variables a, b and c exist, so the strong
normal equivalence class test cases are identical to the weak normal equivalence class test cases.
3) Weak Robust Equivalence Class: Considering the invalid values for a, b and c yields the following additional
weak robust equivalence class test cases

ID "a" "b" "c"
WR1 1 5 5 Invalid Value of a
WR2 5 -1 5 Invalid Value of b
WR3 5 5 -1 Invalid Value of c
WR4 201 5 5 Out of Range Value of

a

a

a
4) Strong Robust Equivalence Class: Test Cases falling under this category are

ID "a" "b" "c"
SR1 -1 5 5 Invalid Value of a
SR2 5 -1 5 Invalid Value of b
SR3 5 5 -1 Invalid Value of c
SR4 -1 -1 5 Invalid Value of a & b
SR5 5 -1 -1 Invalid Value of b & c
SR6 -1 5 -1 Invalid Value of a & c
SR7 -1 -1 -1 Invalid Value of a , b &

c
It may be noted that the expected outputs describe the invalid input values thoroughly.
Tutorial -5: To Generate Equivalence Class Test cases – For Tax Calculation Problem
Equivalence Partitioning refers to a testing technique, with two prime goals like:
1) Reduction of number of test cases to the bare minimum.

2) Identification of the ideal test cases, which should be able to cover maximum number of scenarios.
Equivalence Partitioning is typically applied to the inputs of a tested component, although in some isolated cases it
can be used on the outputs of components in the software application. Equivalence Partitioning technique utilizes a
subset of data which is representative of a larger class.
Equivalence partitioning involves partitioning of the input domain of a software system into several equivalent
classes in a manner that the testing of one particular representative from a class is equivalent to the testing of
some different value from the subject class. Since it is practically not possible to carry out testing so exhaustively,
the other better alternative is to verify to check as to whether the program treats a particular input groups in a
similar way or not. In case some group of similar values are present in the input domain, then such values can be
treated as a single equivalent class & any single representative out of them can be tested. Equivalence Partitioning
is carried out as a substitute of doing exhaustive testing for each value of data in a larger class. The methodology
may be described with the help of following example.
Consider an example program where we consider "Pay" having a valid range of inputs as 12000 to 35000. Amount
of Tax is calculated by the program with following assumptions:
1) Pay up to a sum of Rs. 15000 – Tax Value is Zero

2) Pay from 15001 to 25000 – Tax value is 18 % of Pay
3) Pay above 25000 – Tax value is is 20% of Pay
Let us closely watch that the assumptions provide a definite hint that the program treats some set of values in the
input domain as "equivalent". This way we can create following three valid equivalent classes in the valid input
domain:
Class c1: Having values in a range of 12000 to 15000

Class c2: Having values in a range of 15001 to 25000
Class c3: Having values above 25000
it may not be advisable to restrict our testing to valid set of test cases only. There is a need to test the application
using a set of invalid data as well, since the actual users of the application are likely to provide many invalid inputs,
which can be deliberately or without any such intentions. An invalid class "c4: having values less than 12000" can
be quickly identified. If we assume some maximum limit (Max) for the variable Pay, we can modify the class c3
above to "values in the range 25001...Max and identify an invalid class "c5: values > Max". Max. Value may be
specified either in the specification or can be specified by the constraints of software or hardware at a later date
during the design phase.
To broaden our assumption, let us consider that the program user or the tester types a particular input value using
his keyboard accordingly the corresponding equivalence classes can be described as under.
Since the input has to be "Pay" it is evident that the program treats the non-numeric and numeric values
differently. Thus following two classes can be created as under
- Non-numeric values Class of

- Numeric values Class
Because the program considers all non-numeric values as invalid, there is no need to further divide the class c1.
Since the program does not treat all elements in the class alike, there is a necessity of doing further subdivision of
class with numeric values. Hence, we can identify following classes within this class having set of values satisfying
similar conditions within the program.
- Values < 12000

- Values in the range 12000 to 5000
- Values in the range 15001 to 5000
- Values in the range 25001 to Max
- Values More than Max
There is a no necessity of doing further subdivision of all these equivalent classes, since the program shall treat all
the values in every class with similarity.
Hence following table describes various equivalent classes identified according to the defined specifications
together with group of sample test cases created with the help of the above classes.
Class Input Condition Desired Output Observed Remarks

(For Pay) (Tax amount) Output
c1 – Class of A Non-numeric value Error Msg: "Invalid

Non-numeric Input"
Values
c2 - Values < A Numeric value < Error Msg: "Invalid

12000 12000 Input"
c3 - Values in A Numeric value No Tax

the range >=12000 and <=
12000 to 15000 15000
c4 - Values in A Numeric value Tax = 18% of Pay

15001 to 25000 25000
c5 - Values in A Numeric value Tax = 20% of Pay

25001 Max Max
c6 - Values > A Numeric value > Error Msg: "Invalid

Max Max Input"
From the above illustration, we can conclude that :
1) For creating the test cases with Equivalence Partitioning, having input values within a valid range we need to
identify the following:
a) One valid input value falling within the range

b) One invalid input value falling below the range
c) One invalid input value going above the range
2) For creating the test cases for some definite group of values, we need to identify the following:
a) One valid case corresponding to each value in the set

b) One invalid value e.g.: Test Cases applicable to different type of Bank Accounts like Savings account or Current
account can be
1) Savings Account, Current Account – Are valid cases

2) Overdraft – is an invalid case
Tutorial -9: To Find out the Roots of a Quadratic Equation & Generate its Boundary Value Test Cases
Inputs for the Tutorial: A quadratic equation a(x2)+bx+c=0 with input as three positive integers a, b, c having
values ranging from an interval [0,100].
Objective of this Tutorial: There are two objectives of the tutorial like:
Objective –1: To write a Program in C++ for the determining the nature of roots of the above quadratic equation.
The program output may have one of the following words:
"Not a Quadratic Equation", "Real Roots", "Imaginary Roots" or "Roots are Equal"
Objective –2: Boundary Value Testing by designing Test Cases which would use input variables at their Minimum
Values, Just above Minimum Values, at Nominal Value, Just below Maximum and Minimum Values.
Solution Part – 1: Program in C++
#include
#include
void main( )
{
clrscr( );
int a,b,c,d;
cout<<"The quadratic equation is of the type a(x 2)+bx+c=0"<
cout<<"Enter the value of a:"<
cin>>a;
cout<<"Enter the value of b:"<
cin>>b;
cout<<"Enter the value of c: "<
cin>>c;
d = (b*b)-4*a*c;
if((a<0)||(b<0)||(c<0)||(a>100)||(b>100)||(c>100))
cout«"Invalid input"«end1;
elseif(a==0)
cout<<"Not a quadratic equation"<
elseif(d==0)
cout<<"Roots are equal"<
else if(d<0)
cout<<"Imaginary roots"<
else
cout<<"Real roots"<
getch();
}
Solution Part – 2: Design Boundary Value Test Cases
In the above program, we consider the values as 0 (Minimum), 1 (Just above Minimum), 50 (Nominal), 99 (Just
below Maximum) and 100 (Maximum)
Test a b c Expected Output

Case
ID
1 50 50 0 Real Roots
3 50 50 50 Imaginary Roots
9 50 100 50 Equal Roots

10 0 50 50 Not a Quadratic Equation
Some of the screenshots with different outputs are as under:
1) Screenshot with Output as " Imaginary Roots" is as under
2) Screenshot with Output as "Real Roots" is as under
3) Screenshot with Output as "Roots are Equal" is as under

4) Screenshot with Output as "Not a Quadratic Equation" is as under
Tutorial -10: To Find out the area of a Triangle, Square, Rectangle and a Circle & generate its Equivalence Class Test
Cases
Objective –1: To write programs in C++ for the determining the areas of a Triangle, Square, Rectangle & a circle.
Objective –2: Equivalence Class Testing by designing Test Cases for all i.e. Triangle, Square, Rectangle & circle
#include
#include
#include
void main()
{
clrscr();
int ch;
char c;
float, b, h, a;
1: cout<<"Enter your choice";
cout<<"\n1.Triangle";
cout<<"\n2.Square";
cout<<"\n3.Rectangle";
cout<<"\n4.Circle";
cout<<"\n5.Exit\n";
cin>>ch;
switch(ch)
{ case 1 : b: cout<<"\nEnter the base of the triangle (1-200)";
cin>>b;
if ((b<=0)||(b>200))
{ cout<<"\nInvalid entry for base \n";
goto b;
h: cout<<"\nEnter the height of the triangle (1-200)";
cin>>h;
if ((h<=0)||(h>200))
{ cout<<"\nInvalid height \nEnter the height (1-200)";
goto h;
a= 0.5*b*h;
cout<<"\nThe area is "<< FONT>

cout<<"\nWant to enter more?(y/n) ";
cin>>c;
if((c=='y')||(c=='Y'))
goto 1;
break
case 2 : s: cout<<"\nEnter the side of the square (1-200)";
cin>>b;
if ((b<=0)||(b>200))
goto s;
a= b*b;
cin>>c;
if((c=='y')||(c=='Y'))
goto 1;
break;
case 3: d: cout<<"\nEnter the base of the triangle (1-200)" ;
cin>>b;
if((b<=0)||(b>200))
( cout<<"\nInvalid entry for base \n";
goto d;
p: cout<<"\nEnter the height of the triangle (1-200) ";
cin>>h;
if ((h<=0)||(h>200))
{ cout<<"\nInvalid height \nEnter the height(1-200)";
goto p;
a=b*h;
cin>>c;
if((c=='y')||(c=='Y'))
goto 1;
break;
case 4: t: cout<<"\nEnter the radius of the circle ";
cin>>b;
if ((b<=0)||(b>200))
goto t;
a= 3.14*b*b;
cout<<"\nWant to enter more?(y/n)";
cin>>c;
if ((c=='y')||(c=='Y'))
goto 1;
break;
case 5: exit(0);
break;
default : cout<<"\n WRONG CHOICE";
goto 1;
}
getch();
Solution Part – 2: Equivalence Class Test Cases
In Equivalence Class Testing, we find two types of equivalence classes 1) Input Domain and 2) Output Domain.
Input Domain is formed from one valid sequence and two invalid sequences. The Output Domain is obtained from
different types of outputs of the problem.
Case – 1: Triangle
Input Domain:
I1 = {h : h<=0}
I2 = {h : h>200}
I3 = {h : 1<=h<=200}
I4 = {b : b<=0}
I5 = {b : b>200}
I6 = {b : 1<=b<=2001}
Test Cases for the Case of Triangle are as under:
Test h b Expected Output

Case
ID
1 0 100 Invalid Input
2 100 100 5000
5 100 100 5000
Output Domain:
O1 = {: Triangle if h > 0, b > 0}
O2 = {: Not a triangle if h <= 0, b <= 0}
Screenshot of output with Inputs of Triangle is as under:

Case – 2: Square
Input Domain:
I1 = {s : s<=0}
I2 = {s : s>200}
I3 = {s : 1<=s<=200}
Test Cases for the Case of Square are as under:
Test s Expected
Case Output
ID
1 0 Invalid Input
2 100 10000
3 201 Invalid Input
Output Domain:
O1 = {: Square if s>}
O2 = {: Not a square if s <= 0}
Screenshot of output with Inputs of Square is as under:

Case – 3: Rectangle
Input Domain:
I1 = {l : l<=0}
I2 = {l : l>200}
I3 = {l : 1<=l<=200}
I4 = {b : b<=0}
I5 = {b : b>200}
I6 = {b : 1<=b<=200}
Test Cases for the Case of Rectangle are as under:
Test l b Expected
Case Output
ID
2 100 100 10000
5 100 100 10000

Screenshot of output with Inputs of Rectangle is as under:
Case – 4: Circle
Input Domain:
I1 = {r : r<=0}
I2 = {r : r>200}
I3 = {r : 1<=r<=200}
Test Cases for the Case of Circle are as under:
Test r Expected
Case Output
ID
1 0 Invalid Input
2 100 31400
3 201 Invalid Input
Output Domain:
O1 = {: Circle if 1<=r<=200}
O2 = {: Not a Circle if r <= 0}
Screenshot of output with Inputs of Circle is as under:
Tutorial -11: To calculate the value of (a to the power b) & Generate its Decision Table based Test Cases
Inputs for the Tutorial: An expression ( ab ) with input as two integers a & b.
Objective –1: To write a Program in C++ for the determining the value of expression ( ab ).
Objective –2: Decision Table Based testing for situations in which a number of combinations of actions shall be
taken for different conditions. Four parts of decision table being covered shall be: Condition Stub, Action Stub,
Condition Entries and Action Entries.
#include
#include
#include
void main()
c1rscr();
int a,b;
float c;
char ch;
I : cout<<TO P < b?\n?; power the to `a CALCULATE>
cin>>;
c=pow(a,b);
cout<<<; P <>
cout<<"\nWant to enter again?(y/n)
cin>>ch;
if((ch=='y')||(ch=='Y'))
goto I;
getch();
Solution Part – 2: Decision Table Based Test Cases
Test a b Expected Output

Case
ID
1 2 3 +ve Result
2 -1 3 -ve Result
3 -2 -4 +ve Result
4 0 1 Result is 0
5 0 0 Domain Error
6 -1 -0.6 Result is 1
Decision Table is as under
Conditions
C1:a = 0,b = 0 T
C2:a = -ve, b = +ve T
C3:a = +ve, b = -ve T
C4:a = -ve, b = -ve T
C5:a = +ve, b = +ve T

C6:a = 0, b = integer T
C7:b = 0, a = integer T
C8:a = -ve, b = -ve odd T
Actions
A1: Domain Error X
A2: Negative Output X
A3: Output = 1 X
A4: Positive Output X X X
A5: Output = 0 X
Screenshot with different outputs is as under:
Tutorial -12: To calculate the value of previous date & generate its Decision Table based Test Cases
Inputs for the Tutorial: The present Date is an input as two integers a & b.
Objective –1: To write a Program in C++ for the determining the value of previous dates based upon various
combinations of present date as input.
Objective –2: Decision Table Based testing for situations in which a number of combinations of actions shall be
taken for different conditions. Four parts of decision table being covered shall be: Condition Stub, Action Stub,
Condition Entries and Action Entries.
#include
#include
int main()
{
int day, month, year, flag=0;
printf(" enter the day value;");
scanf("%d",&day) ;
printf("enter the month value;");
scanf("%d",&month);
printf("enter the year value;");
scanf("%d",&year) ;
if(year> = 1900 && year< = 2025)
{
if(month==l||month==3||month==5||month==7||month==8||month==10||month==12)
{
if(day> = 1&&day<=31)
{
flag = 1;
}
else
{
flag = 0;
}
}
elseif (month==2)
{
int rval=0;
if(year%4==0)
{
rval=l;
if((year%100)==0 && (year%400)! = 0
{rval = 0;
}
}
if(rva1==&&(day>=1 &&day <=29))
{ flag = 1;
}
elseif (day>=1 &&day <=28)
{ flag = 1;
else
}
flag = 0;
}
}
if (flag)
{
if(day==1)
{
if(month==1)
{
year--;
day = 31;
month = 12;
}
else if(month==3)
{
int rval = 0;
if(year%4==0)
{
rval = 1;
if ((year%100) == 0 && (year%400): = 0)
{ravl = 0;
}
}
if (ravl==1)
{
day = 29;
month--;
}
else
{
day = 28;
month--;
}
}
else if (month==2|| month==4||month==6||month==9||month==)
{day = 31;
month--;
}
else
{
day = 30;
month--;
}
}
else
{
day--;
}
printf ("the next data is:%d-%d-%d", day, month, year) ;
}
else
{
printf ("the entered data is invalid: %d-%d-%d, day, month, year)
{
getche();
return 1;
}
Solution Part – 2: Decision Table Based Test Cases
Test Month Day Year Expected Output

Case
ID
1 June 1 1964 31 May 1964
2 June 21 1984 Impossible
3 May 1 1945 30 April 1945
4 March 31 2007 30 March 2007
5 August 29 2007 28 August 2007
6 February 29 1962 Impossible
Screenshot with a sample output is as under:

Tutorial -13: To Generate Decision Table based Test Cases for a Payroll Problem
Objective of the Tutorial: To generate test cases for the payroll problem based upon decision table based testing
technique
Consider the payroll system of a person
(a) If the salary of a person is less than equal to Rs. 70,000 and expenses do not exceed Rs. 30,000 then 10% tax
is charged by IT department.
(b) If the salary is greater than Rs.60,000 and less than equal to Rs 2lakhs and expenses don't exceed Rs. 40,000
than 20% tax is charged by IT department.
(c) For salary greater than Rs 2 lakhs, 5% additional surcharge is also charged. (d) If expenses are greater than
Rs. 40,000 surcharge is 9%.
Step – 1: First of all we need to identify the causes and its effects.
Causes Effects
C1 : Salary < = 70,000 E1 : 10% tax is charged.
C2 : Salary > 60,000 and E2 : 20% tax is charged.

Salary < = 2 lacs
E3 : (20% tax) + (5% surcharge) is
C3 : Salary > 2 lacs charged.
C4 : Expenses < = 30,000 E4 : (20% tax) + (9% surcharge) is

charged.
C5 : Expenses < = 40,000
C6 : Expenses > 40,000
Step – 2: Draw the following cause-effect graph
Step – 3: Transform cause-effect graph into the following decision table. It may be noted that these 'causes' and
'effects' are nothing else but 'conditions' and 'actions' of our decision table.
1 2 3 4
Condition / Cause C1 1 0 0 0
Action / Effect E1 X - - -
Action / Effect E2 - X - -
Action / Effect E3 - - X -
Action / Effect E4 - - - X
That is, if C1 and C4 are 1 (or true) then the effect (or action) is E1. Similarly, if C2 and C5 is 1 (or true), action to
be taken is E2 and so on.
Step 4. Since there are 4 rules in our decision table above, so we must have at least 4 test cases to test this
system using this technique.
These test cases can be
1. Salary = 20,000, Expenses = 2000.

2. Salary = 1,00,000, Expenses = 10,000
3. Salary = 3,00,000, Expenses = 20,000
4. Salary = 3,00,000, Expenses = 50,000.
Thus we can say that a decision table is used to derive the test cases which can also take into account the
boundary values.
Tutorial -14: To read the sides of a Triangle & check its shape & perform complete Path Testing on it
Inputs for the Tutorial: A triangle having three sides a, b and c with their values in the range of 0 to 100 as
integers.
Objective –1: To write a Program in C++ for the checking as to whether the triangle is either of : Equilateral
Triangle, Isosceles Triangle, Scalene or "Not a Triangle".
Objective –2: To perform Path Testing on the above & derive the following:
1) Flow Graph
2) DD Path Graph
3) Independent Paths
4) Cyclomatic Complexity
#include
#include
(1) int main ()
(2) {
(3) int a, b, c, validinput = 0;
(4) printf("Enter the side `a' value:")
(5) scanf("%d",&a);
(6) printf("Enter the side `b' value:")
(7) scanf("%d",&b);
(8) printf("Enter the side `c' value:")
(9) scanf(%d", %c);
(10) if((a>0)&&(a<100)&&(b>0)&&(b<=100)&&(c>0)&&(c<=100))
{
(11) if(((a+b)>c)&&((c+a)>b)&&((b+c)>a))
{
(12) validInput=l;
(13) }
(14) }
(15) else
}
(16) validInput=-l;
(17) }
(18) if(validInput==1)
{
(19) if((a==b)&&(b==c))
{
(20) printf("The triangle is EQUILATERAL");
(21) }
(22) else if((a==b)||(b==c)||(c==a))
{
(23) printf("The triangle is ISOSCELES");
(24) }
(25) else
{
(26) printf("The triangle is SCALENE");
(27) }
(28) }
(29) elseif(validInput==0)
{
(30) printf("The values do not constitute a triangle");
(31) }
(32) else
{
(33) printf("The inputs belong to invalid range");
(34) }
(35) getche();
(36) return 1;
(37) }
Solution Part – 2:
A) Mapping Table for DD path Graph
Flow Graph DD Path Graph Remarks

Nodes Corresponding
Nodes
1 to 9 A Sequential Nodes
10 B Decision Nodes
11 C Decision Nodes
12,13 D Sequential Nodes
14 E Two edges are joined

here
15,16,17 F Sequential Nodes
18 G Decision nodes plus

joining of two edges
19 H Decision Nodes
20,21 I Sequential Nodes
22 J Decision Nodes
23,24 K Sequential Nodes
25,26,27 L Sequential Nodes
28 M Three edges combined

here
29 N Decision Nodes
30,31 O Sequential Nodes
32,33,34 P Sequential Nodes
35 Q Three edges combined

here
36,37 R Sequential nodes with

exit node
B) Independent Paths
1) ABFGNPQR
2) ABFGNOQR
3) ABCEGNPQR
4) ABCDGIMOQR
5) ABFGHIMQR
6) ABFGHJKMQR
7) ABFGHJLMQR
C) Cyclomatic Complexity
The Cyclomatic Complexity or the Structural Complexity of the above code can be found by using the formulae
V(G) = e - n + 2P
where V(G) is the cyclomatic metric of Graph 'G' with 'n' vertices, 'e' edges and 'P' connected components.
In this case, the value of e = 23, n = 18 and P = 1.
Therefore, the value of V (G) comes out to be 7
Screenshot – 1: For an Equilateral Triangle

Screenshot – 2: For an Isosceles Triangle
Correct Answers to Objective Type Questions on Black Box Testing are at the end of this page:
Q. 1: Why we need to perform both types of testings like Functional as well as Structural Testing?
A functional (Black Box) test case might be taken from the documentation description of how to perform a certain function. For
example, accepting the bar code input. On the other hand, a structural test case might be taken from a technical documentation
manual.
Both methods together validate the entire system and is shown in Table below
Sr. Test Phase Performed by Verification Validation

Testers and
1 Requirements Developers, X
Review Users
2 Unit Testing Developers X
3 Integrated Developers X
Testing
4 System Testing Developers, X

Users
<<<<<< =================== >>>>>>
Q. 2: What is the source of knowledge for Functional Testing ?
The following items are the knowledge source of functional (or Black Box) testing
1) Requirements Document.
2) Specifications.
3) Domain knowledge.
4) Defect Analysis data.
<<<<<< =================== >>>>>>
Q. 3: What is Special Value Testing?
It is a soft of functional testing technique. It is most intuitive and least uniform. Special value testing occurs when a tester uses his or
her domain knowledge, experience with similar programs and information about soft-spots (i.e., critical areas) to device test cases. It
is also known as adhoc testing. It is tester's ability dependent. Even though special value/adhoc testing is highly subjective, it often
results in a set of test cases that is more effective in revealing faults than the test cases generated by other methods.
<<<<<< =================== >>>>>>
Q. 4: What is Random Testing?
Random testing is a testing technique in which instead of always choosing the min, min+, nom, max- and max values of a bounded
variable, we use a random number generator to pick test case values. This will and biasing also during testing.
<<<<<< =================== >>>>>>
Q. 5: What are the differences between Static Testing and Dynamic Testing?
Sr. Static Testing Dynamic Testing
1 It talks about prevention. It talks about cure.
2 It is more cost effective It is less cost effective.
3 It may achieve 100% It may achieve less than 50%

statement coverage. statement coverage as it finds the
errors only in the part of codes
that are actually executed.
4 It is not time consuming. It is time consuming as it may

involve running several test cases.
5 It can be done before It can be done only after

compilation. executables are ready
<<<<<< =================== >>>>>>
Q. 6: What are the advantages and disadvantages of functional test cases?
Functional test cases have two main advantages
1) They are independent of how the software is implemented. So, even if the implementation changes, the test cases are still useful.
2) Test case development can occur in parallel with the implementation, thereby reducing overall project development internal.
Functional test cases have two main disadvantages
1) Some unavoidable redundancies may exist among test cases.
2) There exists a possibility of gaps of untesting software.

Both of these problems can be solved if we combine the test cases, so obtained from both functional and structural testing.
<<<<<< =================== >>>>>>
Q. 7: What are the differences between Positive Testing and Negative Testing?
Sr. Positive Testing Negative Testing
1 Positive Testing tries to prove that a Negative Testing is done to show

given product does what it is that the product does not fail when
supposed to do. an unexpected input is given.
2 A positive test case is one that A negative test case will have the
verifies the requirements of the input values that may not have
product with a set of expected been represented in the SRS.
output. These are unknown conditions for
the product.
3 The purpose of positive testing is to The purpose of negative testing is

prove that the product works as per to try and break the system.
the user specifications.
4 Positive testing checks the product's Negative testing covers scenarios

behaviour. for which the product is not
designed and coded.
5 Positive testing is done to verify the Negative testing is done to break

known test conditions. the product with unknown test
conditions i.e., test conditions that
lie outside SRS.
6 If all documented requirements and There is no end to negative testing

test conditions are covered then it and 100% coverage is impractical
gives 100% coverage. here.
For example: A product delivering For example: A product not

an error when it is expected to give delivering an error when it should
error. or delivering an error when it
should not.
<<<<<< =================== >>>>>>
Q. 8: What is Domain Testing?
Domain testing is a sort of testing strategy wherein we do not look even at SRS of a software product but test purely on the basis of
domain knowledge and expertise in the domain of application.
For example, in some banking software, knowing the account opening, closing etc. processes, enables a tester to test that
functionality better.
<<<<<< =================== >>>>>>
Q. 9: What is Documentation Testing?
Documentation testing is a testing done to ensure that the documentation is consistent with the product.
<<<<<< =================== >>>>>>
Q. 10: What are the characteristics of a good test?

1) A good test has a high probability of finding an error.
2) A good test is not redundant.
3) A good test is the "best of breed".
4) A good test should be neither too simple nor too complex.

Firstly Let Us Understand The Meaning of Black Box Testing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Firstly Let Us Understand The Meaning of Black Box Testing

Uploaded by

Copyright:

Available Formats

Introduction to Black Box Testing Techniques

Firstly let us understand the meaning of Black Box Testing.

1) Boundary Value Analysis (BVA)

2) Equivalence Class Testing

3) Decision Table based testing

4) Cause-Effect Graphing Technique

1) Boundary Value Analysis (BVA):

2) Equivalence Class Testing:

a) When exhaustive testing is desired.

b) When there is a strong need to avoid redundancy.

3) Decision Table Based Testing:

4) Cause-Effect Graphing Technique:

Boundary Value Analysis (BVA) – A Black Box Testing Technique

Robustness Testing is another variant of BVA

Guidelines for BVA:

Equivalence Class Testing - Black Box Software Testing Techniques

Types of equivalence class testing:

What are Decision Tables?

(a) Stub portion

Structure of decision table: Please refer following decision table

Step – 2: Develop a cause-effect graph.

Step – 3: Transform this cause-effect graph, so obtained in step 2 to a decision table.

Step – 4: Convert decision table rules to test cases.

What are the Advantages of Decision Tables:

What are the Disadvantages of Decision Tables:

Guidelines for Decision Table Based Testing:

# High cyclomatic complexity.

Step 4. Since there are 11 rules, we get following 11 test cases

Guidelines for Cause-Effect Functional Testing Technique:

Comparison among various Black Box or Functional Software Testing Techniques

Effect of various Testing Stretegies on Testing Efficiency:

How to measure Testing Effectiveness of these Testing Techniques:

Key Guidelines for the Functional Testing

3) If the variables are dependent, decision table testing should be practiced.

Various Scenarios & appropriate Black Box Testing Techniques

Good Kiviat chart showing all metrics within limits:

Need of the Concept of Balance in Kiviat Charts:

Let us consider a problem having multiple dimensions like the following:

1) Computer : having processor, printer, disks, CDROM, modem etc.

Method of creating Kiviat Charts:

Kiviat charts are usually drawn by using the following steps:

Step - 1: Choose factors to be measured.

Step - 4: Mark of the values on the factor axes.

Step - 5: Join the marks to form a "star'.

Step - 6: Evaluate the result.

We shall now consider four different cases to draw Kiviat Charts.

Case 1: Kiviat charts - A perfectly balanced system:

Consider a sample data given below.

Case 2: Kiviat charts - A well balanced system:

Consider a sample data for a well-balanced system as given below.

It's Kiviat chart is also shown below

Consider a sample data for a poorly-balanced system as given below.

It's Kiviat chart is also shown below

Consider a sample data for a perfectly-balanced system as given below.

It's Kiviat chart is also shown below

a) Two valid test cases covering extreme ends

1) Pay up to Rs. 15000 – Tax is Zero

Class c1 : Values in the range 12000 to 15000

a) Testing of a compiler using an empty source code

C4: a < b+c

C5: b < a+c

C6: c < a+b

Hence for our case number of inputs or n = 3