This lesson explains why testers will usually find that Mixed-Strength scenarios provide a better balance of "additional thoroughness" vs. "additional time required" than regular 3-way, 4-way, 5-way, or 6-way tests.
Many testers new to this kind of testing are too quick to use sets of 3-way tests when they are seeking more-thorough coverage than pairwise sets can provide
Instead of executing an entire set of higher strength tests, it is usually more efficient and effective to execute a set of Mixed-Strength tests instead. These tests have the ability to include more thoroughness in selected areas (where you want the extra thoroughness). Sets of Mixed-strength scenarios will usually be fewer in number than "regular" higher strength models.
There are only two possible reasons that a set of 2-way tests could fail to trigger a software defect:
There was a missing test "idea" (e.g., the only way the defect could be found is if the application were tested using a specific operating system and that specific system was not included as one of the parameters/values).
All of the test ideas and test conditions were included as values, but the defect could only be triggered by the scenario that included three or more of those existing test conditions together at the same time.
In our experience working with hundreds of software teams, the first reason (not thinking to include a particular test idea) is responsible for more defects slipping by testing than the second one (specific combinations of 3 or more already-included ideas).
Accordingly, this is what is recommended for testers who are planning to manually execute sets of 3-way scenarios:
Don't*
At least not until you first experiment a bit with executing well-thought-through sets of Mixed-Strength scenarios
Why? 90% of the extra thoroughness you might be looking for can probably be achieved by a well-thought-out set of mixed-strength tests. These tests might be half as numerous as the full, "regular" higher-strength test set.
With the extra time that the team saves by not executing all of those additional tests, they should use it to add more wrinkles/testing ideas into their testing.
*This advice is for manual testing projects (where the costs of executing extra tests is relatively high), not for automated test execution projects (where the costs of executing extra tests is relatively low).
Examples of good sources for additional testing ideas include these:
J. Michael Hunter's "You Are Not Done Yet" (Link to PDF)
Elisabeth Hendrickson's Test Heuristics Cheat Sheet - Data Type Attacks & Web Tests (Link to PDF)
Bug reports from this product (or similar products)
Your business rules and technical specs
Adding more scope (e.g., adding in an additional type of user, even when different types haven't previously been considered in scope)