Test Case Design Techniques with Examples

Introduction

Test design is a process that describes “how” testing should be done. It includes processes for identifying test cases by enumerating steps of the defined test conditions.

• Test design is the act of creating and writing test suites for testing software.
• Test analysis and identifying test conditions give us a generic idea for testing which covers quite a large range of possibilities. But when we come to make a test case, we need to be very specific. In fact, now we need the exact and detailed specific input. But just having some values to input to the system is not a test, if you don’t know what the system is supposed to do with the inputs, you will not be able to tell that whether your test has passed or failed.

Test Design Technique

Software Testing Techniques help you design better test cases. There are many different types of software testing technique, each with its own strengths and weaknesses. Each individual technique is good at finding particular types of defect and relatively poor at finding other types.

For example, since exhaustive testing is not possible; Manual Testing Techniques help reduce the number of test cases to be executed while increasing test coverage. They help identify test conditions that are otherwise difficult to recognize.

Broadly speaking there are two main categories of Test Design Techniques. They are:

1. Static Techniques
2. Dynamic Techniques

We will be broadly discussing DYNAMIC testing techniques. There are 5 important software testing techniques: 

• Boundary Value Analysis (BVA)
• Equivalence Class Partitioning
• Decision Table based testing.
• State Transition
• Error Guessing

1.Boundary Value Analysis (BVA)

Boundary value analysis (BVA) is based on testing the boundary values of valid and invalid partitions. It includes maximum, minimum, inside or outside boundaries, typical values and error values.

 The Behavior at the edge of each equivalence partition is more likely to be incorrect than the behaviour within the partition, so boundaries are an area where testing is likely to yield defects. It is also known as BVA and gives a selection of test cases which exercise bounding values.

This comes under the black-box testing technique. Thus, if a system works well for these particular values then it will work perfectly well for all values which comes between the two boundary values.

Guidelines for Boundary Value analysis

• If an input condition is restricted between values x and y, then the test cases should be designed with values x and y as well as values which are above and below x and y.
• If an input condition is a large number of values, the test case should be developed which need to exercise the minimum and maximum numbers. Here, values above and below the minimum and maximum values are also tested.

Example:

Input condition is valid between 1 to 10

Boundary values 0,1,2 and 9,10,11

2. Equivalence Class Partitioning

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

The concept behind this technique is that the test case of a representative value of each class is equal to a test of any other value of the same class. It allows you to Identify valid as well as invalid equivalence classes.

Example:

Input conditions are valid between

 1 to 10 and 20 to 30
Hence there are five equivalence classes

--- to 0 (invalid)
1 to 10 (valid)
11 to 19 (invalid)
20 to 30 (valid)
31 to --- (invalid)
You select values from each class, i.e.,
-2, 3, 15, 25, 45

3. Decision Table Based Testing.

A decision table is a good way to deal with different combination inputs with their associated outputs. It is a black box test design technique to determine the test scenarios for complex business logic.

It is also known as to Cause-Effect table because of an associated logical diagramming technique called cause-effect graphing that is used to derive the decision table. This software testing technique is used for testing the system behaviour for different input combinations.

The first task is to identify functionalities where the output depends on a combination of inputs. If there are large input set of combinations, then divide it into smaller subsets which are helpful for managing a decision table.

For every function, you need to create a table and list down all types of combinations of inputs and its respective outputs. This helps to identify a condition that is overlooked by the tester.

Example: The condition states that if the user provides the correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed.

Conditions	Rule 1	Rule 2	Rule 3	Rule 4
Username	F	T	F	T
Password	F	F	T	T
Output	E	E	E	H

In the above example,

• T – Correct username/password
• F – Wrong username/password
• E – Error message is displayed
• H – Home screen is displayed

4. State Transition

State Transition Testing is a black-box testing technique that is carried out to observe the behaviour of the system or application for different input conditions passed in a sequence. In this type of testing, both positive and negative input values are provided and the behaviour of the system is observed. In-State transition technique, the testing team provides positive as well as negative input test values for evaluating the system behaviour.

Example:

In the following example, if the user enters a valid password in any of the first three attempts the user will be able to log in successfully. If the user enters the invalid password in the first or second try, the user will be prompted to re-enter the password. When the user enters password incorrectly 3rd time, the action has taken, and the account will be blocked.

State transition diagram

In this diagram when the user gives the correct PIN number, he or she is moved to Access granted state. 

In the above, when the user enters the correct PIN, the state is transitioned to Access granted. And if the user enters an incorrect password, he or she is moved to the next state. If he does the same 3rd time, he will reach the account blocked state.

5. Error Guessing

Error guessing is a software testing technique which depends on speculating the mistake which can win in the code. It is an encounter-based system where the test expert uses his/her or experience to figure the problematic piece of the testing application.

The technique counts a list of possible errors or error-prone situations. At that point, tester composes an experiment to expose those errors. To design test cases based on this software testing technique, the analyst can use past experiences to identify the conditions.

Test Design Tools

Test design tools help to run test cases, or if nothing else test inputs (which is a piece of a test case). 

For an example, if the requirements are kept in a test management tool or a Computer-Aided Software Engineering (CASE) tool used by developers, then it is possible to identify the input fields, including the range of valid values. This range of information can be used to make out boundary values and equivalence partitions. If the valid range is stored, the tool can distinguish between values that should be accepted and those that should not be accepted and generates an error message. If the error messages are stored, then the expected result can be checked in detail. If the expected result of the input of a valid value is known, then that expected result can also be included in the test case constructed by the test design tool.

Another type of test design tool is sometimes called a ‘screen scraper’, a structured template or a test frame. The tool looks at a window of the graphical user interface and identifies all of the buttons, lists and input fields, and can set up a test for each thing that it finds. This means that every button will be clicked for example and every list box will be selected. This is a good start for a thorough set of tests and it can quickly and easily identify non-working buttons. But if the tool does not have access to an oracle, it may not know what should happen as a result of the button click.

Note that the test design tool may not have a complete solution – that is, it may know which input values are to be accepted and rejected, but it may not know the exact error message or resulting calculation for the expected result of the test. Thus the test design tool can help us to get started with test design and will identify all of the fields, but it will not do the whole job of test design for us – there will be more verification that may need to be done.

Features or characteristics of test design tools are:

• To generate test input values from:

Requirements;
Design models (state, data or object);
Code;
Graphical user interfaces;
Test conditions;

• To generate expected results, if an automated oracle is available to the tool.