randomly.
If you are interrupted during a test, you may do something twice, or something apparently extraneous that should be harmless (for example, turn a terminal or printer on or off, or press a key then press <Delete>). Try to remember exactly what you did just before the interruption, what fidgeting you did during the interruption, and what you did just after you got back to work.
U
SER ERROR:Y
OU DIDN'
T DO WHAT YOU THOUGHT YOU DIDThis will often be the explanation for a "bug." As long as you don't repeat your error, you won't be able to recreate the bug. Even though this is a likely guess, accept it only when you run o ut of alternatives.
If you think that people will make this error frequently, and the program's response to it is unacceptable, report a problem with the program's error handling. Don't ignore your errors. Carefully examine what the computer does with them.
A
N EFFECT OF THE BUG MAKES REPLICATION IMPOSSIBLEBugs can destroy files, write into invalid memory areas, disable interrupts, or close down I/O ports. When this occurs you can't reproduce a problem until you recover the files or restore the computer to its proper (or previous) state.
Here's an example of this type of problem. One of your customers sends you a letter of complaint and a floppy disk. To replicate the problem you start the program, load the disk, run the test and OOPS, the bug trashes the data files on the customer's disk. You've reproduced the problem once, but now until you get another copy of the disk from the customer, you'll never reproduce it again.
To avoid problems like this, make sure to back up data files before attempting to replicate a bug.
^ — ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Never, never, never use the original source of the data. Always use copies.
T
HE BUG IS MEMORY-
DEPENDENTThe program may fail only when a specific amount or type of memory is available. Another memory-specific condition may be that the total amount of available memory appears adequate, but it turns out to be too fragmented (spread across smaller blocks that are not contiguous).
A message box that displays the amount of free memory, perhaps also showing the sizes of the five largest blocks, can be extremely handy. You see how much memory is available at the start of a test, and so, how far to reduce available memory to truly reproduce a problem. Further, this helps you understand how much memory each operation uses, making it much easier to get the program back into the original memory state. (These memory dialogs are often put in for debugging purposes, accessed by a special key, but they are often left in programs for product support use later. They are very handy.)
86
—\
T
HIS IS A FIRST-
TIME-
ONLY(
INFTIAL STATE)
BUG■
In the classic case, when you run the program for its first time, one of its first tasks is to initialize its configuration data file on disk. If you can get the program to do anything else before initialization, it will misbehave. As soon as initialization of the data file is complete, however, the program will work fine. This error will only be seen the very first time the program is run. Unfortunately, it might be seen by every person who buys the program when it is run for the first time.
As a variant of this problem, a program might not clean out the right parts of the computer's memory until after running for a while. Rather than finding O's, the program might find what it thinks is data. What it has really found is junk left over from the last program that was running. Once the program initializes this area of memory, you won't see the problem again until you reload the other programs into memory, then reload this on top of them.
The question to ask is how to get the computer, the program, and the data files into the state they were in before the program misbehaved. To answer this question perfectly you have to know all the changes the program makes and when it makes them. You probably don't know this (if you did, you could reproduce the bug), so returning everything to initial states won't be easy. If you suspect initialization problems test from its initial state, turn off the computer and start over with a never-used copy of the program (make a supply of them.)
B
UG PREDICATED ON CORRUPTED DATAThe program might corrupt its own data, on disk or in memory, or you may have fed the program bad data. The program chokes on the data, or detects the error but stumbles in the error handler. In either case, the error you're seeing is one of error detection and recovery. To reproduce the error, you must give the program the same data again. This sounds obvious, but every tester misses this point sometime.
B
UG IS A SIDE-
EFFECT OF SOME OTHER PROBLEMThis is an error recovery failure. The program fails, then, in handling the error, the program fails again. Often the second failure is much worse than the first. In watching the spectacular crash caused by the second bug, you may not notice that tiny first glitch. Your objective, after you realize that there is a first bug, is to reproduce the first one. The second one reproduces easily after that.
INTERMITTENT HARDWARE FAILURE
Hardware failures arc usually complete. Usually, for example, a memory chip will work or it won't. But heat build-up or power fluctuations may cause intermittent memory failures or memory chips may work loose and make intermittent connection. Data or code in memory are only occasionally corrupted. If you think this is