Test Case Design Techniques

In general a lot of techniques are used while designing/preparing the test cases. These techniques help us to limit the number of inputs to be tested for testing the specified range or boundaries. We will discuss about two of the most prominent of these techniques. These techniques are called

• Boundary Value Analysis (BVA)
• Equivalence Class Partition

Boundary value analysis/ testing: - A test case design technique for a component in which test cases are designed which include representatives of boundary values. A testing technique using input values at, just below, and just above, the defined limits of an input domain; and with input values causing outputs to be at, just below, and just above, the defined limits of an output domain.

Equivalence Class: - A portion of a component's input or output domains for which the component's behavior is assumed to be the same from the component's specification

Equivalence Partitioning: - A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes

Let's understand these two techniques using a simple example. Below given is a sample specification for a Login page of an application.

Specifications: - 1) Application is having a Login Page containing two text boxes User Name, Password. It also have two command buttons Login, Reset.

2) The Login Text box should accept alphanumeric input only.

3) The password should be a minimum of 6 characters and a maximum of 10 characters. And it should contain at least one special character, One Alphabet and One Number.

Application of Boundary Value Analysis (BVA) technique:-

BVA can be stated in other words as; if L, U are the Lower and Upper limits of a range of input, then the tendency of having a defect is most likely at values L-1, L, L+1, U-1, U, U+1.

Now let us look at the Specification#3. It says that the password should have a length between 6 to 10 characters. In this case

Lower Boundary (L) = 6

Upper Boundary (U) = 10

So we need to consider testing with input having 5 (L-1), 6 (L), 7 (L+1), 9 (U-1), 10 (U), 11 (U+1) characters as these are the value that are most likely to cause a failure/defect.

At a first look, it may not seem to have saved us from creating number of test cases. Now assume that the lower and upper bounds are 2, 100 respectively. In order to design test cases for this kind of input range imagine the test cases you need to design without using the BVA technique. At a minimum you need to test with 100 inputs. If you apply BVA for this scenario the inputs reduce to 1, 2, 3, 99, 100, and 101. May be we can check for one more input between 3, 99 to be on safe side. So the total inputs we need to use reduced to 7. Do you see the effect of applying BVA now?

Application Equivalence Class Partition technique:-

In simple terms Equivalence Class Partition can be stated as testing with one representative from each equivalence class is enough to prove the success or failure of testing with the entire equivalence class.

Let us look at the Specification#2. It says that Login text box should accept only alphanumeric input. This means no special characters allowed. Once special character comes into picture the input becomes Invalid. As long as you use combination of alphabets and Numerals (Alphanumeric) the input is Valid.

Now, we can divide our input into two partitions Valid and Invalid Input. This forms our first level of partitions.

Let's look at the valid inputs now. We can use only Numbers, Only Alphabets, and combination of both Numbers and Alphabets as input. This leads us to the new partitions Numbers Only Input, Alphabets Only Input, Alphanumeric Input. Like this we can go on identifying different partitions based on the specification and need.

So if we put all of this at one place we get the following partitions.

• VALID INPUT
•      Numbers Only
•      Alphabets Only
•      Alphanumeric
• INVALID INPUT
•      Special Characters Only
•      Alphanumeric + Special Characters

Now, if you test one input in the Numbers Only partition, we can safely apply the result of this test to all values in the same partition. So testing with one input from each partition is enough to cover testing of the entire partition. In our example we can test with 5 inputs in total and identify the outcome of all these five partitions. So, this way we can reduce our effort to create number of test cases.

Now two more definitions that are of use and indirectly related to the concepts we discussed above.

Coverage Testing (Test Coverage):- Coverage testing is concerned with the degree to which test cases exercise or cover the logic (source code) of the software module or unit. It is also a measure of coverage of code lines, code branches and code branch combinations

Code Coverage: - An analysis method that determines, which parts of the software code have been executed (covered) by the test case suite and which parts of code have not been executed and therefore may require additional attention.