_edited_edited.png)
Test design is an important part of the software testing process as it helps to ensure that the software meets the requirements and is defect free. To create effective test suites, it's important to identify what needs to be tested and what doesn't, as well as how to stimulate the system with relevant data values. Additionally, it's essential to determine how the system should react and respond to those stimuli to ensure that it functions as intended.
Test case design techniques can be very helpful in achieving maximum test coverage while minimizing the number of actual test cases needed. Some popular techniques are :
Equivalence Partitioning
Boundary Value Analysis
Decision Table Testing
State Transition Testing
Error Guessing
Equivalence Partitioning
Equivalence partitioning technique also called, equivalence class partitioning testing, divides the input data into different partitions or groups, and each partition represents a set of valid or invalid states for the input data. Test cases are then designed to cover at least one value from each partition or group, ensuring that all possible scenarios are tested without testing every single input combination.
This technique will save time and resources while ensuring thorough testing of the feature or functionality.
Example: Suppose one text field will accept 50 characters. Now we will see how this technique works.
Text Field Can Accept 1-50 character 21-30 31-40 41-50 51-60
If we take 50 valid test cases for all valid input numbers in addition to other test cases for invalid input it will take a long time to complete it. So instead of entering any value one after another we will divide it into ranges or groups. And we can choose one value from each range and test both positive and negative scenarios which save time and number of iterations
Boundary Value Analysis (BVA)
As name suggests we test the test cases at boundary level. There is a rule to follow the BVA. Below table shows we have a range of values 1(Min) and 50(Max). So we need to design test cases as per extreme and intermediate limit. And we will have 6 scenarios.
Boundary Value Analysis (BVA)
Invalid (min-1) | Valid(min,+min,-max,max) | Invalid(max+1) |
0 | 1, 2, 49, 50 | 51 |
Decision Table Testing
Decision tables are a useful tool in software testing to help ensure that all possible combinations of inputs and outputs are tested, especially when there are complex business rules involved. By organizing the conditions and actions in a clear, visual way, testers can more easily identify which test cases need to be executed and ensure that all possible scenarios are covered.
While designing decision tables we must identify the conditions(inputs) and the resulting actions(outputs).Each column in the table represents a unique decision rule that defines a combination of conditions when met, it trigger the execution of the actions associated with that rule.
When creating decision tables, the values of the conditions and actions are typically represented in various formats, such as:
Boolean values: true or false
Discrete values: e.g., red, green, or blue
Numbers or ranges of numbers
It always good to follow a standard notation which can be understandable by all the stakeholders. Common standard notations are:
For conditions:
Y represents the condition is true (may also be represented as T or 1)
N represents the condition is false (may also be represented as F or 0)
— denotes the value of the condition is not relevant (may also be represented as N/A)
For actions:
X represents the action that should occur (may also be defined as Y or T, or 1)
Blank represents the action that should not happen (may also be described as – or N or F or 0)
Below table shows the decision table for a login functionality.
And Number of test cases will be : No of rules=2 to the power of condition = (2^2) =4
Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
UserId | T | T | F | F |
Password | T | F | T | F |
E | N | Y | Y | Y |
D | Y | N | N | N |
E: Error Display (Invalid Username or Password), D: Display Account Page, T: Valid Input, N: Invalid Input, Y: Action should happen, N: Action should not happen
In the above table conditions are the "UserID and Password inputs". Actions are "Display error message with Invalid Input" and "Display account page with Valid Input"
The decision table explains that when the UserName and Password inputs are correct there will be no error displayed and the user will be redirected to the My Account page. However, if either the UserName or Password value is incorrect, an error message will be displayed.
State Transition Testing
A State Transition Table is an useful technique for visualizing the different states that a system can be in and the events that can cause it to transition from one state to another. By mapping out all of the possible transitions, we can ensure that the system behaves as expected and identify any invalid or unexpected transitions.
There are two primary methods for representing State Transitions: State Transition Diagram and State Transition Table. Let’s take an example of the ATM Withdrawal process.
State Transition Table
| Event 1 (Insert Card) | Event 2 (Enter Pin) | Event 3 (Valid Pin) | Event 3 (InvalidPin) |
S1: Start | S2 | | - | |
S2: Wait for PIN | | S3 | - | |
S3: 1st Try | | | S6 | S4 |
S4: 2nd Try | | | S6 | S5 |
S5: 3rd Try | | | S6 | S7 |
S6: Access to Account | | | | |
S7: Block account | | | | |
As above table shows , after card inserted the system transitions to State 2(S2): "Wait for Pin".
After entering the Pin system transition to S3:"1st Try".
Correct Pin entry during any try, the system transitions to S6: "Access to Account".
Incorrect Pin entry during the 1st try, the system transitions to S4: "2nd Try".
Incorrect Pin entry during the 2nd try, the system transitions to S5: "3rd Try".
Incorrect Pin entry during the 3rd try, the system transitions to S7: "Block account"
State Transition Diagram
Above diagram is the visual representation of the various states that ATM Withdrawal process can take on, as well as the transitions between those states. It helps us understanding how the software behaves in different situations.
Error Guessing
Error guessing is an informal and intuitive testing approach that relies on the tester's experience to identify potential errors or bugs in a software application. The tester might deliberately try unexpected inputs, configurations, or scenarios that might cause the application to fail. By doing so, they can uncover hidden defects that may not be easily detected by formal testing methods. It's important to note that while error guessing can be a useful technique, it should not be the sole method of testing and should be supplemented with formal testing approaches and tools.
We learned above that test case design techniques are crucial for effective and efficient software testing and also it can help to identify the right test scenarios and inputs to achieve maximum test coverage and identify critical defects and improve the overall quality of the software being tested.