This lesson describes how an effective strategy used in a parlor game is directly relevant to software testing.  And why knowing this strategy is not enough.

For anyone unfamiliar with 20 questions, we offer Wikipedia's definition:

"Twenty Questions is a spoken parlor game which encourages deductive reasoning and creativity. It originated in the United States and escalated in popularity during the late 1940s when it became the format for a successful weekly radio quiz program.

In the traditional game, one player is chosen to be the answerer. That person chooses a subject but does not reveal this to the others. All other players are questioners. They each take turns asking a question which can be answered with a simple "Yes" or "No." In variants of the game (see below), multiple state answers may be included such as the answer "Maybe." The answerer answers each question in turn. Sample questions could be: "Is it bigger than a breadbox?" or "Can I put it in my mouth?" Lying is not allowed in the game. If a questioner guesses the correct answer, that questioner wins and becomes the answerer for the next round. If 20 questions are asked without a correct guess, then the answerer has stumped the questioners and gets to be the answerer for another round."

To excel at the game of 20 questions, it is extremely useful to know “the science” of game theory and Design of Experiments.  Choose each of your questions so that there will be a 50/50 likelihood that the answer to the question will be "Yes."  That way you will learn as much as possible with each question.  

To provide an example to reinforce this point, the only thing that you know about what you're guessing is that it is a living person, and you choose between these two options for your next question:

- or -

The second question maximizes your chance of eliminating 50% of the remaining possibilities whereas the first question is likely to remove only a single possibility and leave you with one fewer question.  Hexawise-driven test design is all about trying to give you the maximum possible learning from every single test condition in every single test you execute.

------

Wikipedia's 20 Questions entry provided the following, striking example of how using this simple strategy could have saved 50 years of work for scientists researching light:

"In 1901 Charles Sanders Peirce discussed the potential of Twenty Questions to single one subject out from among 220 and, pointing to skillful caution, said,

'Thus twenty skillful hypotheses will ascertain what two hundred thousand stupid ones might fail to do. The secret of the business lies in the caution which breaks a hypothesis up into its smallest logical components, and only risks one of them at a time.'

He elaborated on how, if that principle had been followed in the investigation of light, its investigators would have saved themselves from half a century of work."

The well-known Design of Experiments book titled "Statistics for Experimenters" points out that you can't win a game of 20 Questions if your opponent is thinking about Abraham Lincoln's stovepipe hat, but you've never heard of Abraham Lincoln. Having some expertise in the relevant subject matter is critical.

What is true for winning in 20 questions is also true in creating software tests.  

While Hexawise can combine your existing test ideas in ways that will make you more efficient and effective than you could otherwise be on your own, other knowledge is absolutely indispensable as well in order to design highly effective software tests.

You can’t consistently excel at 20 Questions or software testing unless you have a good mix of both:

and

A specific example makes this point: only a very small percentage of software testers have the subject matter expertise to find the answer to this testing challenge.  Using Hexawise to try to find the solution may very well help once you have a few test ideas to experiment with but if you can't think of any test ideas to experiment with, Hexawise won't be able to help.