UNIT-II

SOFTWARE TESTING
TOPICS COVERED :
EQUIVALENCE CLASS TESTING: Equivalence Classes, Weak
Normal Vs Strong Normal Equivalence Class Testing, Weak Robust
Vs Strong Robust Equivalence Class Testing, Equivalence Class Test
Cases for the Triangle Problem, Equivalence Class Test Cases for the
Next Date Function and Equivalence Class Test Cases for the
Commission Problem, Guidelines for Equivalence Class Testing.

DECISION TABLE BASED TESTING: Decision tables, Test cases

for the triangle problem, Test cases for the Next Date function, Test
cases for the commission problem, Guidelines and observations.

DATA FLOW TESTING: Definition Use Testing, Example- The

Commission Problem, Slice-Based Testing, Guidelines and
Observations.

INTRODUCTION :
Equivalence Class Testing :

Equivalence Class Testing, which is also known as Equivalence Class

Partitioning (ECP).

Equivalence Partitioning, is an important software testing technique used by

the team of testers for grouping and partitioning of the test input data, which is
then used for the purpose of testing the software product into a number of
different classes.

These different classes resemble the specified requirements and common

behaviour or attribute(s) of the aggregated inputs. Thereafter, the test cases are
designed and created based on each class attribute(s) and one element or input is
used from each class for the test execution to validate the software functioning,
and simultaneously validates the similar working of the software product for all
the other inputs present in their respective classes.
Equivalence Class Testing Example

Let us further clear the concept of equivalence class testing with the assistance
of the following example:

Consider a software application, which takes not less than two digit number and
not more than 3 digit number, for its execution. Given below is the huge amount
of input to test and validate the functioning of the software application.

1,2,3,.................1498,1499,1500.

 Now, as per the requirement specifications, these inputs are grouped

together to form some classes. Now, instead of testing 1500 inputs, we
have formed 4 classes and are accordingly dividing the inputs into a
category of valid and invalid inputs, which reduces the work of the test
case preparation.

 A single element, chosen from each class, as a test input, represents the
whole class. For example, number 121 is used from the class "three digit
numbers" as the test input. On using 121, it was found that software
application functions properly and passes the test. Therefore, it is
assumed that all the other numbers of the class "three digit number" will
work well for the software application. And if the software fails the test,
then it is assumed, that all the three digit numbers will generate error in
the software application.

 Similarly, a number 7 is used from the class "single digit numbers", i.e.
invalid input. It is expected by the software application, to generate error,
on using number 7, and if does then the software is functioning
appropriately, and it is also assumed that the remaining single digit
number will also produces error(s), in the software application.
Features of Equivalence Class Testing:

Equivalence class testing can be termed as a logical step in the model

of functional testing. It improves the quality of test cases, which further
enhances the quality of testing, by removing the vast amount of redundancy and
gaps that appear in the boundary value testing. Other features of this testing
technique are:

 It is a black box testing technique which restricts the testers to examine

the software product, externally.

 Also known by the name of equivalence class partitioning, it is used to

form groups of test inputs of similar behaviour or nature.

 Based on the approach, if one member works well in the family then the
whole family is considered to function well and if one members fails,
whole family is rejected.

 Test cases are based on classes, not on every input, thereby reduces the
time and efforts required to build large number of test cases.

 It may be used at any level of testing i.e. unit, integration, system &
acceptance.

 It is good to go for the ECT, when the input data is available in terms of
intervals and sets of discrete values.

 However, there is no such specific rule to use only input from each class.
Based on the experience and need, a tester may opt for more than one
input.

 It may results into good amount of decrease in the redundant test cases, if
implemented properly.
  It may not work well with the boolean or logical types variables.

 A mixed combination of Equivalence class testing and boundary value

testing produces effective results.

 The fundamental concept of equivalence class testing/partition comes

from the equivalence class, which further comes from equivalence
relations.

Equivalence Class Testing Types:

The equivalence class testing can be categorized into four different types, which
are integral part of testing and cater to different data set. These types of
equivalence class testing are:

1. Weak Normal Equivalence Class Testing: In this first type of

equivalence class testing, one variable from each equivalence class is
tested by the team. Moreover, the values are identified in a systematic
manner. Weak normal equivalence class testing is also known as single
fault assumption.

2. Strong Normal Equivalence Class Testing: Termed as multiple fault

assumption, in strong normal equivalence class testing the team selects
test cases from each element of the Cartesian product of the equivalence.
This ensures the notion of completeness in testing, as it covers all
equivalence classes and offers the team one of each possible
combinations of inputs.

3. Weak Robust Equivalence Class Testing: Like weak normal

equivalence, weak robust testing too tests one variable from each
equivalence class. However, unlike the former method, it is also focused
on testing test cases for invalid values.
 4. Strong Robust Equivalence Class Testing: Another type of equivalence
class testing, strong robust testing produces test cases for all valid and
invalid elements of the product of the equivalence class. However, it is
incapable of reducing the redundancy in testing.

Advantages & Disadvantages of Equivalence Class Testing:

Equivalence class testing or equivalence partitioning plays a potent role in

reducing redundancy in testing and making the process agile and powerful. It is
among those testing techniques that offer numerous benefits to the team and
ensures compliance of the product with customer requirements. However, there
are few drawbacks associated to this type of testing, which are listed below
along with its various advantages.

Advantages:

 Equivalence class testing helps reduce the number of test cases, without
compromising the test coverage.

 Reduces the overall test execution time as it minimizes the set of test
data.

 It can be applied to all levels of testing, such as unit testing, integration

testing, system testing, etc.

 Enables the testers to focus on smaller data sets, which increases the
probability to uncovering more defects in the software product.

 It is used in cases where performing exhaustive testing is difficult but at

the same time maintaining good coverage is required.
Disadvantages:

 It does not consider the conditions for boundary value.

 The identification of equivalence classes relies heavily on the expertise of

testers.

 Testers might assume that the output for all input data set are correct,
which can become a great hurdle in testing.

Guidelines for Equivalence Class Testing:

By following a set of guidelines while implementing the process of testing, the

team of testers can ensure better outputs from the tests and make sure all
scenarios are being tested accurately. Therefore, listed below are some
tips/guidelines for equivalence class testing:

 Use robust forms if the error conditions in the software product are of
high priority.

 It can be used by the team in projects where the program function is

complex.

 To ensure the accuracy and precision of equivalence class testing, define

the input data in terms of intervals and sets of discrete values.

 Use of robust from is redundant of the implemented language is strongly

types and when invalid values cause runtime errors in the system.

 The team needs to select one valid and one invalid input value each, if the
input conditions are broken or not stated accurately.

 Establishing proper equivalence relation might require several tries and

extra efforts of the team.
Difference Between Equivalence Class Testing & Boundary Value
Analysis:

Boundary value analysis and equivalence class testing are two strategies used
for test case designing in black box testing, which makes it crucial for us to
differentiate them from one another and define their specific relevance in
software testing. The differences between these two are:

Equivalence Class Testing Boundary Value Analysis

1. Equivalence Class Testing is a 1. Next part of Equivalence Class

type of black box technique. Partitioning/Testing.

2. It can be applied to any level of 2. Boundary value analysis is

testing, like unit, integration, usually a part of stress & negative
system, and more. testing.

3. A test case design

3. This test case design technique
technique used to divide input
used to test boundary value
data into different equivalence
between partitions.
classes.

4. Reduces the time of testing, 4. Reduces the overall time of test

while using less and effective test execution, while making defect
cases. detection faster & easy.

5. Tests only one from each

5. Selects test cases from the edges
partition of the equivalence
of the equivalence classes.
classes.

Equivalence class testing, also known as Equivalence Class Partitioning

(ECP), is a valuable black-box testing technique used during software testing.
What Is Equivalence Class Testing?
Equivalence class testing involves grouping and partitioning test input data into
different classes based on common behaviour or attributes.
These classes represent logical partitions, and all data items within an
equivalence class are assumed to be processed in the same way by the software
application when passed as input.

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.
EQUIVALENCE CLASS TEST CASES FOR THE TRIANGLE
PROBLEM.

we’re dealing with a program that takes three integers, a, b, and c, representing
the sides of a triangle. The program’s output can fall into one of the following
categories:

1. Equilateral Triangle: All three sides are of equal length.

2. Isosceles Triangle: Two sides are of equal length, while the third side is
different.
3. Scalene Triangle: All three sides have different lengths.
4. Not a Triangle: When the input sides cannot form a valid triangle (e.g.,
the sum of any two sides is less than or equal to the third side).

Now, let’s break down the input and output domains and create equivalence
classes for testing:
1. Output Domain:
o O₁: Not a triangle (when any side is greater than the sum of the
other two).
o O₂: Equilateral Triangle.
o O₃: Isosceles Triangle.
o O₄: Scalene Triangle.
2. Input Domain:
o I₁: (0 < a \leq 10)
o I₂: (a < 0)
o I₃: (a > 10)
o I₄: (0 < b \leq 10)
o I₅: (b < 0)
o I₆: (b > 10)
o I₇: (0 < c \leq 10)
o I₈: (c < 0)
 o I₉: (c > 10)
3. Equivalence Classes:
o I₁₀: (a = b = c) (Equilateral Triangle)
o I₁₁: (a = b, b \neq c) (Isosceles Triangle)
o I₁₂: (b = c, c \neq a) (Isosceles Triangle)
o I₁₃: (a = c, c \neq b) (Isosceles Triangle)
o I₁₄: (a \neq b \neq c) (Scalene Triangle)
o I₁₅: (a + b = c) (Not a Triangle)
o I₁₆: (a + b < c) (Not a Triangle)
o I₁₇: (b + c = a) (Not a Triangle)
o I₁₈: (b + c < a) (Not a Triangle)
o I₁₉: (c + a = b) (Not a Triangle)
o I₂₀: (c + a > b) (Not a Triangle)
4. Test Cases and Program Results:

Table

Class a b c Expected Output Program Output Tested Outcome

O₁ 10 5 5 Not a Triangle Not a Triangle Pass

O₂ 5 5 5 Equilateral Triangle Equilateral Triangle Pass

O₃ 1 5 5 Isosceles Triangle Isosceles Triangle Pass

O₄ 10 9 5 Scalene Triangle Scalene Triangle Pass

I₁ 5 5 5 Equilateral Triangle Equilateral Triangle Pass

I₂ 0 5 5 Invalid Input Invalid Input Pass

 Class a b c Expected Output Program Output Tested Outcome

I₃ 11 5 5 Invalid Input Invalid Input Pass

I₄ 5 5 5 Equilateral Triangle Equilateral Triangle Pass

I₅ 5 0 5 Invalid Input Invalid Input Pass

I₆ 5 11 5 Invalid Input Invalid Input Pass

I₇ 5 5 5 Equilateral Triangle

Equivalence Class Testing- Next date problem :

 
Equivalence class testing (Equivalence class Partitioning) is a black-box
testing technique used in software testing as a major step in the Software
development life cycle (SDLC). This testing technique is better than many of
the testing techniques like boundary value analysis, worst case testing, robust
case testing and many more in terms of time consumption and terms of
precision of the test cases. Since testing is done to identify possible risks,
equivalence class testing performs better than the other techniques as the test
cases generated using it are logically identified with partitions in between to
create different input and output classes. This can be shown from the next-date
problem which is stated below:
Given a day in the format of day-month-year, you need to find the next date for
the given date. Perform boundary value analysis and equivalence-class testing
for this.

Conditions :
 D: 1<Day<31

M: 1<Month<12

Y: 1800 <Year <2048

Boundary Value Analysis:

No. of test Cases (n = no. of variables) = 4n+1 = 4*3 +1 =13
Test Cases:
Test Case ID Day Month Year Expected Output

1 1 6 2000 2-6-2000

2 2 6 2000 3-6-2000

3 15 6 2000 16-6-2000

4 30 6 2000 1-7-2000

5 31 6 2000 Invalid Date

6 15 1 2000 16-1-2000

7 15 2 2000 16-2-2000

8 15 11 2000 16-11-2000

9 15 12 2000 16-12-2000

10 15 6 1800 16-6-1800

11 15 6 1801 16-6-1801

12 15 6 2047 16-6-2047

13 15 6 2048 16-6-2048

Equivalence Class Testing:

Input classes:
Day:
D1: day between 1 to 28
D2: 29
D3: 30
D4: 31
Month:
M1: Month has 30 days
M2: Month has 31 days
M3: Month is February
Year:
Y1: Year is a leap year
Y2: Year is a normal year
Output Classes:
Increment Day
Reset Day and Increment Month
Increment Year
Invalid Date

Strong Normal Equivalence Class Test Cases:

 Test Cases:
Test Case ID Day Month Year Expected Output

E1 15 4 2004 16-4-2004

E2 15 4 2003 16-4-2003

E3 15 1 2004 16-1-2004

E4 15 1 2003 16-1-2003

E5 15 2 2004 16-2-2004

E6 15 2 2003 16-2-2003

E7 29 4 2004 30-4-2004
E8 29 4 2003 30-4-2003

E9 29 1 2004 30-1-2004

E10 29 1 2003 30-1-2003

E11 29 2 2004 1-3-2004

E12 29 2 2003 Invalid Date

E13 30 4 2004 1-5-2004

E14 30 4 2003 1-5-2003

E15 30 1 2004 31-1-2004

E16 30 1 2003 31-1-2003

E17 30 2 2004 Invalid Date

E18 30 2 2003 Invalid Date

E19 31 4 2004 Invalid Date

E20 31 4 2003 Invalid Date

E21 31 1 2004 1-2-2004

E22 31 1 2003 1-5-2003

E23 31 2 2004 Invalid Date

E24 31 2 2003 Invalid Date

EQUIVALENCE CLASS TESTING FOR THE COMMISSION
PROBLEM:
What is a commission problem?
The Commission Problem is a scenario where we need to calculate
commissions based on certain input parameters. Let’s break it down:
1. Inputs:
o Locks (L): The number of locks sold. It satisfies the condition (1
\leq L \leq 70).
o Month: The month for which the commission is being calculated.
It can be a month with 30 days, 31 days, or February (which can
have 28 or 29 days).
o Year: The year for which the commission is being calculated. It
can be a leap year (varying days in February) or a normal year.
2. Output:
o The commission amount based on the given inputs.
3. Equivalence Class Testing:
o We define equivalence classes for the inputs to create efficient test
cases.
o For example, we consider different ranges of locks (e.g., 1-28, 29,
30, 31) and various months and years.
o We also identify output classes such as incrementing the day,
resetting the day and incrementing the month, incrementing the
year, and handling invalid dates.
4. Example Test Cases:
o Let’s assume the following input values:
 Locks = 15
 Month = April
 Year = 2004
 o The expected output would be: 16-4-2004 (incrementing the day).

Remember that this problem involves handling dates and commissions, and the
test cases cover various scenarios to ensure the function works correctly.
Equivalence class testing for the Commission Problem. Equivalence class
testing is a powerful technique used in software testing to create efficient and
logically identified test cases based on input and output classes. It’s particularly
useful when compared to other techniques like boundary value analysis and
worst-case testing.

Now, let’s consider the Commission Problem. Suppose we have a function that
calculates the commission based on certain input parameters. We’ll focus on
generating test cases using equivalence class testing.

Problem Statement:

Given a commission calculation function, we need to identify relevant input and

output classes for testing. Here are the conditions:

 Locks (L): 1 ≤ L ≤ 70
 Output Range: Commission can be positive or negative (e.g., -1 if locks
= -1 is used to control input iteration)

Equivalence Classes Defined on Input Space:

1. Locks (L):
o D1: Locks between 1 and 28.
o D2: Exactly 29 locks.
o D3: Exactly 30 locks.
o D4: Exactly 31 locks.
2. Month:
o M1: Months with 30 days.
o M2: Months with 31 days.
 o M3: February (which can have 28 or 29 days).
3. Year:
o Y1: Leap years (varying days in February).
o Y2: Normal years.

Output Classes:

1. Increment Day: Commission calculation when the day increments.

2. Reset Day and Increment Month: Commission calculation when the
day resets and the month increments.
3. Increment Year: Commission calculation when the year increments.
4. Invalid Date: Commission calculation for invalid dates.

Strong Normal Equivalence Class Test Cases:

1. E1: Locks = 15, Month = 4, Year = 2004 → Expected Output: 16-4-2004

2. E2: Locks = 15, Month = 4, Year = 2003 → Expected Output: 16-4-2003
3. E3: Locks = 15, Month = 1, Year = 2004 → Expected Output: 16-1-2004
4. E4: Locks = 15, Month = 1, Year = 2003 → Expected Output: 16-1-2003
5. E5: Locks = 15, Month = 2, Year = 2004 → Expected Output: 16-2-2004
6. E6: Locks = 15, Month = 2, Year = 2003 → Expected Output: 16-2-2003
7. E7: Locks = 29, Month = 4, Year = 2004 → Expected Output: 30-4-2004
8. E8: Locks = 29, Month = 4, Year = 2003 → Expected Output: 30-4-2003
9. E9: Locks = 29, Month = 1, Year = 2004 → Expected Output: 30-1-2004
10.E10: Locks = 29, Month = 1, Year = 2003 → Expected Output: 30-1-
2003
11.E11: Locks = 29, Month = 2, Year = 2004 → Expected Output: 1-3-2004
12.E12: Locks = 29, Month = 2, Year = 2003 → Expected Output: Invalid
Date
 13.E13: Locks = 30, Month = 4, Year = 2004 → Expected Output: 1-5-2004
14.E14: Locks = 30, Month = 4, Year = 2003 → Expected Output: 1-5-2003
15.E15: Locks = 30, Month = 1, Year = 2004 → Expected Output: 31-1-
2004
16.E16: Locks = 30, Month = 1, Year = 2003 → Expected Output: 31-1-
2003
17.E17: Locks = 30, Month = 2, Year = 2004 → Expected Output: Invalid
Date
18.E18: Locks = 30, Month = 2, Year = 2003 → Expected Output: Invalid
Date
19.E19: Locks = 31, Month = 4, Year = 2004 → Expected Output: Invalid
Date
20.E20: Locks =

Decision Table Based Testing in Software Testing



What is a Decision Table ?
Decision tables are used in various engineering fields to represent complex
logical relationships. This testing is a very effective tool in testing the software
and its requirements management. The output may be dependent on many input
conditions and decision tables give a tabular view of various combinations of
input conditions and these conditions are in the form of True(T) and False(F).
Also, it provides a set of conditions and its corresponding actions required in the
testing.
Parts of Decision Tables:
In software testing, the decision table has 4 parts which are divided into
portions and are given below :
 1. Condition Stubs : The conditions are listed in this first upper left part of
the decision table that is used to determine a particular action or set of
actions.
2. Action Stubs : All the possible actions are given in the first lower left
portion (i.e, below condition stub) of the decision table.
3. Condition Entries : In the condition entry, the values are inputted in the
upper right portion of the decision table. In the condition entries part of
the table, there are multiple rows and columns which are known as Rule.
4. Action Entries : In the action entry, every entry has some associated
action or set of actions in the lower right portion of the decision table and
these values are called outputs.
Types of Decision Tables :
The decision tables are categorized into two types and these are given below:
1. Limited Entry : In the limited entry decision tables, the condition entries
are restricted to binary values.
2. Extended Entry : In the extended entry decision table, the condition
entries have more than two values. The decision tables use multiple
conditions where a condition may have many possibilities instead of only
‘true’ and ‘false’ are known as extended entry decision tables.
Applicability of Decision Tables :
 The order of rule evaluation has no effect on the resulting action.
 The decision tables can be applied easily at the unit level only.
 Once a rule is satisfied and the action selected, n another rule needs to be
examined.
 The restrictions do not eliminate many applications.
Example of Decision Table Based testing :
Below is the decision table of the program for determining the largest amongst three
numbers in which its input is a triple of positive integers (x,y, and z) and values are
from the interval [1, 300].
Table 1 : Decision Table of largest amongst three numbers :
Conditi R R R R R R R R R R1 R1 R1 R1 R1
ons 1 2 3 4 5 6 7 8 9 0 1 2 3 4
c1: x >
F T T T T T T T T T T T T T
= 1?

c2: x <=
F T T T T T T T T T T T T
300?

c3: y >
F T T T T T T T T T T T
= 1?

c4: x <=
F T T T T T T T T T T
300?

c5: z >
F T T T T T T T T T
= 1?

c6: z <=
F T T T T T T T T
300?

c7:
T T T T F F F F
x>y?

c8:
T T F F T T F F
y>z?

c9:
T F T F T F T F
z>x?

Rule 25 12 6 3 1
8 1 1 1 1 1 1 1 1
Count 6 8 4 2 6

a1 :
Invalid X X X X X X
input

a2 : x is
X X
largest

a3 : y is
X X
largest
 a4 : z is
X X
largest

a5 :
Impossi X X
ble

QUESTIONS AND ANSWERS :

1. Define equivalence class testing?
2. Write about weak normal , strong normal equivalence class testing?
3. Write short note on weak robust , strong robust Equivalence class testing?
4. Differences between weak normal ,strong normal and weak robust , strong robust ?
5. Explain the guideline of creating test cases in Equivalence class testing?.
6. Explain all the four test cases using equivalence class testing?.
7. Write a short note on decision table based testing?.
8. What are the guidelines for creating decisions table based testing ?
9. Explain all the four test cases using decision table based testing?
10. What is data flow testing?
11. What is control flow testing?
12. What is system flow design?
13. Difference between data flow testing and control flow testing.
14. Explain all the four test cases using decision table based testing.