Software Engineering
Home Planning Requirements Writing Hazard Analysis Requirement Analysis Config Control Software Design Software Testing Software Standards Basic Logic

Basic Logic - The Null Hypothesis

Since the Research Hypothesis cannot be proven, the next logical step is to see if we can fail to disprove it. The Research Hypothesis (H1) is IF A THEN B (i.e. there is a relationship between A and B). The opposite, or Null Hypothesis (H0), is that there is no such relationship. This is the logical NOT of A -> B.

Expanding the truth table for the implies operator to include H0:

A

B

A -> B

NOT
A -> B

0

0

1

0

0

1

1

0

1

0

0

1

1

1

1

0

For NOT A -> B there is only ONE condition that does not produce a contradiction: the condition where A is NOT related to B (shaded row). The Null Hypothesis is therefore a statement that there is NO relationship between A and B.

This is the goal of the negative proof – to show that the opposite of the research hypothesis produces a contradiction and is therefore an invalid argument. So, if B = 1, then the Null Hypothesis cannot be Valid (H0 is rejected), therefore the research hypothesis cannot be Invalid!

This is also called modus tollens, negative proof, or indirect proof.

Note, however, that the Null Hypothesis cannot be proven True – for the same reasons that H1 cannot be proven True - because the validity of the argument still says nothing about the truth of the premises!

So when testing, if we get the expected result (B = 1), we reject the Null Hypothesis, because in every case where B=1, the value of NOT A -> B is False (0). This still does not prove the Research Hypothesis, since the fact that B = 1 does not prove that A = 1; A could still be 0. However, rejection of the Null Hypothesis makes it possible for the Research Hypothesis to be True.

If, however, we do not get the expected result (B = 0), we fail to reject the Null Hypothesis. This still does not reject the Research Hypothesis - it is possible that either A = 0 (we didn't actually create the test condition we intended), or A = 1 and the relationship A -> B truly does not exist (an actual software defect has been found!). Remember, the existence of the relationship A -> B was our original premise, and it could be False!

So, if we get the expected result, either the software works, or something is broken and is giving us a false result. And, if do not get the expected result, then something is broken, we just don't know what. The generic term for this is an Anomaly. This is why it takes many tests to confirm the Research Hypothesis - we need to build up a large enough body of data to believe that all those expected results are caused by working software.

So, one test failure is enough to show that something is broken, but it takes many test passes to convince ourselves that the software is actually working correctly.

CONCLUSION: Testing does not pass because the system works – testing passes because we failed to break the system!

Corollary: Testing must explicitly try to break the system, or it will be unable to demonstrate a failure to break the system.

Points to Remember:
H1 is the research hypothesis, which what we are trying to verify. We want to demonstrate that the statement A -> B is true (i.e. there is a relationship between A and B).

H1 can be neither proven nor disproven.

H0 is the null hypothesis, which the inverse of H1: that there is no relationship between A and B.

H0 can be rejected, but not proven. H0 is rejected if B = 1. If B = 0 then we fail to reject H0 (which is not the same as proving it true, we are only saying that it does not appear false ).

Rejecting H0 lends weight of evidence that H1 may be true.

Failure to reject H0 says that no conclusion can be drawn about the accuracy of H1 (this is not the same as disproving H1).

Therefore, we learn more by rejecting H0 (getting the expected results)  than by failing to reject (getting an anomaly).