My Subject Matter Experts (SMEs) / Business Analysts (BAs) / Quality Assurance (QA) are idiots and can’t understand how to figure out the right test case paths to test our software. Why?

People have a hard time with abstract logical implications. All people.

You learned in discrete math (or logic class) that, given that P implies Q, if you have P, then you must have Q. It’s kind of the definition of implication. In math symbols, the logical implication looks like this:

P -> Q      (P implies Q)
P                (P is true)
——-
Q                (There fore, Q is true)

or, in plain English

If the football game runs late, then 60 Minutes will start late.
The football game ran late.
Therefore, 60 Minutes started late.

Easy to follow, right?

Now, let’s say we turned on the TV and saw that 60 Minutes was running late. A lot of people would say, "Ah ha! The football game must have run late." And you know what? In the real world, that probably was the case. Your QA person would mark your test case as passing!

But, what if instead the President decided to talk after the game and the game had actually finished on time? Then, your conclusion that the ball game ran late would be false. Hmm . . .

So, what’s going on here?

It’s that little arrow up there in the math–the implication. It’s only one way. It says, if P then Q. It doesn’t say anything about Q. In fact, there’s no mention of the state of Q except in the result.

In English, we didn’t say, if 60 Minutes is late, then the ball game must have been late. We said, if the ball game is late, then 60 Minutes will be late. And those are two totally different statements.

Lost?

If you are, you’re not alone. In fact, most people have a hard time with this–people like SMEs, BAs and QA. That’s the thing to remember. It’s a problem with people in general–not a specific person.

Don’t believe me? Read this article on the Wason Card Problem. This is a very good lesson in critical thinking. Here’s a short excerpt that might make you click the link above.

Four cards are presented: A, B, 4, and 7. There is a letter on one side of each card and a number on the other side. Which card(s) must you turn over to determine whether the following statement is false? "If a card has a vowel on one side, then it has an even number on the other side."

If you want to know the answer, spend some time reading about the problem here. If you do, you’ll learn more about yourself, people and why your SMEs, BAs and QA have a hard time with those technical requirements and creating test plans. Humans have a confirmation bias. Don’t beat them up. They are only human.

If you read the Wason Card Problem article closely, you might realize that the problem may not be in how the requirements are being interpreted; but, that you have humans interpreting them, and, as such, they are going to have a hard time with abstract concepts.

From the Wason article, when people were given the problem presented in this way,

Let the cards show "beer," "cola," "16 years," and "22 years." On one side of each card is the name of a drink; on the other side is the age of the drinker. What card(s) must be turned over to determine if the following statement is false? If a person is drinking beer, then the person is over 19-years-old.

the studies showed that people had a significantly higher chance at getting the right answer. From the article

Humans are hardwired to solve practical, concrete problems, not abstract ones.

What I have seen over the years is that software developers–abstract thinking people–tend to get involved in complicated parts of writing technical requirements. And, those parts of the requirements represent the A, B, 4 and 7 kind of cards and not the beer, cola, 16 years, and 22 years kind of cards.

This can lend to some very bad testing just because the testers simply don’t see how to prove the statement false.

Now that you’ve experienced this first hand (if you didn’t, you’ve really wasted your time and short changed yourself but it’s not too late to go back to the top and start over), consider changing your requirements a little and helping a fellow human being out. They are, after all, testing your software–ya know?

(Oh, and if you want a lesson in variability, list to this. I like the UB 40 version better than the Elvis version.)