To find programming mistakes
To make sure the program doesn't crash the system
1.3.Error and how do they occur
1.3.1.Imprecise capture of requirements
Imprecision in requirements are the most expensive faults we encounter. Imprecision takes the form of incompleteness,inconsistencies, lack of clarity, ambiguity etc. Faults in requirements are inevitable, however, because requirementsdefinition is a labour-intensive and error-prone process.
1.3.2.Users cannot express their requirements unambiguously
When a business analyst interviews a business user, it is common for the user to have difficulty expressingrequirements because their business is ambiguous. The normal daily workload of most people rarely fits into a perfectlyclear set of situations. Very often, people need to accommodate exceptions to business rules and base decisions on gutfeel and precedents which may be long standing (but undocumented) or make a decision 'on the fly'. Many of the rulesrequired are simply not defined, or documented anywhere.
1.3.3.Users cannot express their requirements completely
It is unreasonable to expect the business user to be able to identify all requirements. Many of the detailed rules thatdefine what the system must do are not written down. They may vary across departments. Under any circumstance, theuser being interviewed may not have experience of all the situations within the scope of the system.
1.3.4.Developers do not fully understand the business.
Few business analysts, and very few developers have direct experience of the business process that a new system is tosupport. It is unreasonable to expect the business analyst to have enough skills to question the completeness or correctness of a requirement. Underpinning all this is the belief that users and analysts talk the same language in thefirst place, and can communicate.
1.4.Cost of a single fault
We know that all software has faults before we test it. Some faults have a catastrophic effect but we also know that not allfaults are disastrous and many are hardly noticeable.
1.4.1.Programmer errors may cause faults which are never noticed
It is clear that not every fault in software is serious. We have all encountered problems with software that causes usgreat alarm or concern. But we have also encountered faults for which there is a workaround, or which are obvious, butof negligible importance. For example, a spelling mistake on a user screen, which our customers never see, which hasno effect on functionality may be deemed 'cosmetic'. Some cosmetic faults are trivial. However, in some circumstances,cosmetic may also mean serious. What might our customers think if we spelt quality incorrectly on our Web site homepage?
1.4.2.If we are concerned about failures, we must test more.
If a failure of a certain type would have serious consequences, we need to test the software to ensure it doesn't fail inthis way. The principle is that where the risk of software failure is high, we must apply more test effort. There is a straighttrade off between the cost of testing and the potential cost of failure.
1.5.1.Exhaustive testing of all program paths is usually impossible
Exhaustive path testing would involve exercising the software through every possible program path. However, even'simple' programs have an extremely large number of paths. Every decision in code with two outcomes, effectivelydoubles the number of program paths. A 100-statement program might have twenty decisions in it so might have1,048,576 paths. Such a program would rightly be regarded as trivial compared to real systems that have manythousand or millions of statements. Although the number of paths may not be infinite, we can never hope to test allpaths in real systems.
1.5.2.Exhaustive testing of all inputs is also impossible
If we disregard the internals of the system and approach the testing from the point of view of all possible inputs andtesting these, we hit a similar barrier. We can never hope to test all the infinite number of inputs to real systems.1.5.3.If we could do exhaustive testing, most tests would be duplicates that tell us nothingEven if we used a tool to execute millions of tests, we would expect that the majority of the tests would be duplicates andthey would prove nothing. Consequently, test case selection (or design) must focus on selecting the most important or useful tests from the infinite number possible.
Effectiveness and efficiency
A test that exercises the software in ways that we know will work proves nothingWe 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 willalmost certainly work, we learn nothing. If we prepare a test that explores a new piece of functionality or a new situation, we