The Number of Test Combinations Rise.
Let's start out with a multiple entry system. Each entry has its own series of categories that have different options and possible statuses. If this were a real system, we would keep on adding combinations. As it grew, the total coverage of tests would also rise. The trick is maintaining good coverage, despite more and more combinations.
Let's add numbers to our system. Imagine that we are working with an application that controls the expenses of our executives, with a simple interface with the following items:
Categories: 4 (each expense can belong to a different category: food, lodging, transportation, etc.).
Forms of payment: 3 (each expense can be paid in three ways: cash, card, and other).
Currency: 2 (dollars or colones).
Status: 2 (the expense may require refunding or it may have been covered by the company).
Ensuring High Test Coverage.
Using an empirical technique to cover every test case combination, we are left with a minimum of 48 test cases (4x3x2x4 possibilities). This doesn’t take into account negative cases or edge cases that could be found in the app.
Knowing we have 48 cases to test the module, the real problem isn't the execution. This would be a relatively easy task, since we know already know all of the combinations. The real issue is the time. How much time does it take to create and execute all 48 test cases? Take into account that our system is only one example. If the daily entries were to rise, then so would the number of combinations.
Reducing the number of test cases.
There is one way to reduce the number of test cases- by using a reliable and powerful tool called all pair testing. All pair testing is a simple, yet powerful and secure tool that, when combined, all possibilities have a high coverage percentage, significantly reducing the number of test cases.
Using our expense control module, the following case-construction steps are as follows.
Step 1.
Organize the categories in a descending manner. In other words, the category with the most entries should go first: Category, Forms of payment, Currency, Status
Step 2.
Type n times the variable of A(Category) in the first column, where n is the number of variables in B (Forms of payment).
Step 3.
Type the “Forms of payment” variables in the second column.
Step 4.
Check, from right to left, that every value from the right column is paired with one in the left column.
Carry out this step every time a new column is added or if the chart is modified.
This way we can see that for every cash-made payment, there is at least one expense for food, lodging, transportation, and others. You may also check the card and other expense pairs.
Step 5.
Add the values of the third variable and make sure to check the right column with the left column.
Step 6.
Once every new value has its pair in another column, the following value list is added.
We can see that, in this case, there is no colones-paid or dollars-refunded pairs. We have to search for a repeated pair and change it's value.
Step 7.
Once a change has been made, you have to repeat the verifying process on the right column with all the left columns, in order to compare pairs, and see if any pairs don’t exist. If this is the case, then they are adjusted and the values are checked again.
Step 8.
Once we check that every value has it's pair, our table is complete.
Conclusion
In the end, we have reduced 48 cases to 12, cutting the number down by 75% of the possible cases that could have been executed without the use of the technique versus the variable combination.
