Generally, people test a program until they have confidence in it. This is a nebulous concept. Generally you will find many errors when you begin testing an individual module or collection of modules. The detected error rate drops as you continue testing and fixing bugs. Finally the error rate is low enough that you feel confident that you have caught all the major problems.
How you test your software depends on the situation. In this section we will look at some of the code developed in previous sections, and see some of the different things we can do to convince ourselves that it is correct. 5.1 Software Test Plans Large projects usually test their product in accordance with a software test plan. Or, at least they SAY they do. The test plan is filled with "motherhood" statements saying that each module will be thoroughly tested, with special emphasis on values just inside and outside the nominal input limits, and values clearly outside the normal input range to stress it. It sounds great on paper, but it is usually impractical. I've never seen a software test plan that wasn't a waste of time.
Suppose you tried to test the Write program in accordance with such a software test plan. What file names are just inside or outside "nominal input limits?" Is "C:\HERECOMES\JAWS.NOW" more stressful than "BAMBI.AAH"? Suppose the file you try to write is an object code file rather than an ASCII text file. What constitutes success or failure?
I don't care what the software test plan says, testing is an Ad Hoc procedure. The incredible amount of time it takes to write, debate, and approve the test plan, (and especially the time it takes to explain why you didn't test in accordance with it), could be much better spent actually testing the software.