Many testers are considering or already using test design techniques, allowing them to reduce the effort in testing and still gain a good insight in the quality of systems and software. Looking at the possibilities and the available literature, often a categorization is made, to ease up technique selection for specific situations.
White-box techniques are supporting the formulation of test cases based on some structure, and are therefore long time seen as something exclusively for developers, as they are the ones working with code, which is seen as such a structure. In contrast, black-box techniques support the design of test cases based on some kind of requirements or specification. Of course a good fit for the business testers as they are mainly using requirements and other specifications to show that the system is behaving as it is supposed to do and giving the results that are expected.
This black-and-white differentiation is not a good and definitely not a correct perspective. Categorizations as such provide us some help in that they ease up our conversation and point out our focus in designing test cases, the categorization should definitely not be treated dogmatically. Professional testers nowadays even combine or integrate the corresponding techniques in exploratory testing.
To widen the perspective of business testers, let us have a look at condition coverage as one of the so-called white box techniques. This technique focuses on having a more in-depth test of complex conditions that represent the underlying rules for a decision in a control flow graph. While we take a look at control flow graphs (representing the structure of a piece of code or of some part of the architecture), we are aware of the fact that control flow graphs use comparable syntax elements as for instance business processes (where statements are activities and decisions … guess what … are decisions), thus the business process as such already allows us to make use of white-box techniques like statement coverage or decision coverage. Within the business processes, the underlying rules of the decision points may evenly contain complex conditions.
Now coverage measures (from the white-box techniques) are typically explained in a very theoretical, almost scientific manner. They are hard to understand and therefore these techniques are not commonly applied. This especially goes for the MCDC technique. MCDC stands for Modified Condition Decision Coverage, one of the condition coverage techniques. This strong technique reduces the number of test cases from 2N to N+1, where N is the number of atomic conditions. Atomic conditions are the individual conditions that are part of the complex condition, e.g. when the complex condition is “A>18 AND B<60”, “A>18” and “B<60” are the atomic conditions.
MCDC is way easier to apply than e.g. decision tables as it takes the approach to directly define the minimal set of test cases, where decision tables take the approach to define the total number of possible test cases and then reduce the numbers in a structured manner.
For MCDC, the rule for designing test cases is that each of the atomic conditions in the complex condition should contribute to a false and once to a true result for the complex condition. That means, changing the value of the atomic conditions directly leads to a change in the result of the complex condition.
Let’s take the example of the complex condition A AND B:
Leaving us with 3 test cases (N+1) instead of 4(2N) test cases.
Now to apply this on even more complex conditions, we apply a “trick” to quickly come up with the corresponding combinations, analyzing the sequential combination of atomic conditions, so for the complex condition “A AND B AND C”, we first analyze A AND B, then B AND C and if the complex condition would be even longer than we would proceed with these same steps for the consecutive pairs:
Now to cover the entire complex condition, we still need to add values for atomic conditions “A” in the “test cases” 4 – 6 and “C” in the “test cases” 1 – 3 (printed in red) as follows:
Applying the following rule:
If the analyzed relation is combined with the other atomic condition with an “AND”-relation, then we add a “1”, whereas with an “OR”-relation, we would add a “0”, to not change the complex condition outcome.
Now we can still reduce the doubles:
Leaving us with N+1 is 4 test cases.
The same approach is helping us in situations which even include combinations of AND and OR and probably also with brackets. As follows:
Filling the gaps accordingly:
And getting rid of the doubles:
If the number of atomic conditions is higher, you just continue this approach and you will end up with N+1 test cases (instead of 2n test cases).
Allocating specific (groups of) test design techniques to different kinds of practical problems sounds like a good support for the tester in general, deciding what to use to strengthen not only the coverage but also the testing profession. However if the categorization leads to an unnecessary reduction of options for the tester, then we should cease using those categories. Categories should be supportive, not a science in itself.
The use of MCDC is in many situations easier and more effective than using decision tables or other techniques. Let us open ourselves up for the techniques and thoughts available in the community, without bothering about barriers that some still try to impose on us.
If you want to learn more about the MC/DC technique, take part in the trendig's training courses for ISTQB Technical Test Analyst or ISTQB Automotive Tester. We can also arrange a 3-hour hands-on training for you and your team at your location or online on all aspects of the MC/DC technique. Please contact us via training@trendig.com.
trendig
