This technique divides the input data of the software into different equivalence data classes and then tests these classes rather than individual inputs. An equivalence data class means that all values in that partition set should lead to the same outcome or yield the same result. Doing this allows for limiting the number of tests considerably.For example, consider an application that accepts an integer value between 1 and 100 (inclusive). Using equivalence partitioning, we can divide the input data into two equivalence classes:
- Valid
- Invalid
To be more precise, we could further divide it into three equivalence classes:
- Class 1: Less than 1 (Invalid)
- Class 2: Between 1 and 100 (Valid)
- Class 3: Greater than 100 (Invalid)
Then we can write three tests, picking one representative from each class (e.g., 0, 50, and 101) to create our test cases. Doing so ensures a broad coverage with minimal test cases, making our testing process more efficient.
Boundary Value Analysis
This technique focuses on the values at the boundary of the input domain rather than the center. This technique is based on the principle that errors are most likely to occur at the boundaries of the input domain.The input domain represents the set of all possible inputs for a system. The boundaries are the edges of the input domain, representing minimum and maximum values.For example, if we expect a function to accept an integer between 1 and 100 (inclusive), the boundary values would be 1 and 100. With Boundary Value Analysis, we would create test cases for these values, values just outside the boundaries (like 0 and 101), and values just inside the boundaries (like 2 and 99).Boundary Value Analysis is a very efficient testing technique that provides good coverage with a relatively small number of test cases. However, it’s unsuitable for finding errors within the boundaries or for complex logic errors. Boundary Value Analysis should be used on top of other testing methods, such as equivalence partitioning and decision table testing, to ensure the software is as defect-free as possible.
Decision Table Testing
This technique uses a decision table to design test cases. A decision table is a table that shows all possible combinations of input values and their corresponding outputs.It’s handy for complex business rules that can be expressed in a table format, enabling testers to identify missing and extraneous test cases.For example, our system only allows access to a user with a valid username and password. Moreover, the system denies access to users when it is under maintenance. The decision table would have three conditions (username, password, and maintenance) and one action (allow access). The table would list all possible combinations of these conditions and the expected action for each combination. Here is an example:
| Valid Username | Valid Password | System under Maintenance | Allow Access |
| True | True | False | Yes |
| True | True | True | No |
| True | False | False | No |
| True | False | True | No |
| False | True | False | No |
| False | True | True | No |
| False | False | False | No |
| False | False | True | No |
The main advantage of Decision Table Testing is that it ensures we test all possible input combinations. However, it can become complex and challenging to manage when systems have many input conditions, as the number of rules (and therefore test cases) increases exponentially with the number of conditions.