A test that exercises the software in ways that we know will work proves nothing.
We know that if we run the same test twice we learn very little second time round. If we know before we run a test, that it will almost certainly work, we learn nothing. If we prepare a test that explores a new piece of functionality or a new situation, we know that if the test passes we will learn something new - we have evidence that something works. If we test for faults in code and we try to find faults in many places, we increase our knowledge about the quality of the software. If we find faults, we can fix them. If we do not find faults, our confidence in the software increases.
When we prepare a test, we should have some view on the type of faults we are trying to detect. If we postulate a fault and look for that, it is likely we will be more effective.
In other words, tests that are designed to catch specific faults are more likely to find faults and are therefore more effective.
If we postulate a fault and prepare a test to detect that, we usually have a choice of tests. We should select the test that has the best chance of finding the fault. Sometimes, a single test could detect several faults at once. Efficient tests are those that have the best chance of detecting a fault.
Reference – ISEB PARTI- Principles of Testing