Warning! This article is a little more technical than usual so if you are a tester or interested in QA then read on, if not ….ah well, read on as well as it is quite interesting!
In this article we look at three concepts on how to design an effective test case and how these concepts work together in testing:
Boundary Value Analysis
Equivalence Partitioning
Decision Tables
When it comes to software testing, the art of crafting the right test cases is crucial for catching critical Issues, bugs and logic flow errors early.
How do testers - including tech geeks - go about designing these test cases?
The Magic of Boundary Value Analysis (BVA)
Let's say you’re standing at the edge of a cliff. You wouldn’t want to be too close to the edge, right? In software testing, those cliff edges are where bugs love to hide! That is where Boundary Value Analysis (BVA) comes into play.
BVA focuses on testing the "edges" or boundaries of input ranges because systems often start to wobble when you get too close to the edge. By testing these boundaries, we can catch those sneaky bugs that might otherwise slip by.
Types of Boundaries:
Inclusive: Exact minimum and maximum values.
Exclusive: Just outside the valid range.
Internal: Points within the range dividing it into smaller parts.
Example: For an age input of 18-60, BVA test cases would include:
17 (exclusive lower boundary)
18 (inclusive lower boundary)
19 and 59 (internal boundaries)
60 (inclusive upper boundary)
61 (exclusive upper boundary)
If the system can handle these edge cases, it’s probably in good shape!
Equivalence Partitioning (EP): The art of grouping
EP helps you reduce the number of test cases by dividing inputs into "equivalence classes" or partitions. Each class is expected to behave the same way, so you only need to test one representative from each group. This means less work but still plenty of coverage!
Using EP & BVA together to derive test cases.
Let's imagine we are testing a field that only allows integers between 1 and 99, we can use a diagram to visualise our test designing process.
Invalid- Too low | Valid | Invalid - Too High |
0 | 1 -99 | 100+ |
At a quick glance the diagram identifies 2 valid tests : 1 , 99 - Verify the Inclusive boundaries.
You can derive at least 3 more valid tests: By isolating the partitions and inputting a values that falls within each of the 3 (Too low, valid and Too High)
2 invalid tests : 0, 100 - Verify the exclusive boundaries.
Now you can derive 3 more invalid tests: by attempting to use Letter, Decimals and Special characters.
Now you can see the power in these methods as now you have a total of 10 potential test cases!
Decision Tables: The ultimate combo planner
Decision Tables help you map out all possible combinations of conditions and their corresponding actions. This method ensures you don’t miss any critical scenarios, especially when dealing with complex business rules.
Creating a decision table:
Identify all conditions and their possible values.
Identify all possible actions or outcomes.
Create a table with columns for conditions, actions, and rules.
List all possible combinations of conditions and their corresponding actions.
Decision table example:
The main idea here is to establish what test cases can be derived from the different combinations of conditions. The example we will use is as follows: Booking a Hotel room
Users Must have a valid ID
Frequent visitors get 5% off
A room must be available
Frequently visiting females receive a Skincare Gift bag
Decision table frame.
Step 1: Identify conditions and actions.
Step 2: How do you identify all the alternate condition combinations?
This decision table uses Booleans, (YES/NO, ON/OFF, True/False) so for each condition there's always only going to be two states. Mathematically you can express this by multiplying your amount of states to the power of your condition count: 2^4= 16 possible alternatives.
At this point you can add your alternative columns , to fill them you must make use of binary partitioning, for example , using 16 columns at the first condition row 8 will be marked as true the remaining 8 will be false.
For the next condition: Divide each of the T and F segments in half again. Fill the first quarter with T, the second with F, the third with T, and the fourth with F.
Continue this pattern until you've filled the table.
This table now represents all possible alternative conditions , you might also have noticed that our first Condition was: “Valid ID” . Well if the user doesn't have a valid id the test cant even continue so do we need all the test cases involving invalid IDs ?
The short answer is no so we can collapse the table and lessen our testing load.
Step 3: Use the business logic to fill the actions section
Using the business logic above we can fill in the actions:
Now we can see that not all the conditions invoke action, so again we can cut this table down to the tests that cover all case results.
And just like that you have derived 7 test cases out of your conditions, the removed test cases should not be run as this would violate the second principle of testing: Exhaustive testing is impossible. Since for example if you have 8 conditions you will have 256 Condition alternatives… this is not reasonable as it will take very long to complete.
Bringing It all together
Boundary Value Analysis, Equivalence Partitioning, and Decision Tables might sound like technical jargon, but when you break them down, they’re all concepts that are logical for testing.
By understanding and applying these techniques, you can significantly improve the quality of your test cases and increase your chances of finding defects early in the development process.