1. Don't take anything for granted.
Keep notes of everything you do - every step, every pause, everything. It's easy to leave out a step or add one unintentionally. you could use a keystroke and mouse recording program so that you can record and playback your steps exactly. Use a video camera to record your test session if necessare.
The goal is to make sure that every detail of the steps necessary to cause the bug are visible and can be analyzed from a different view.
2. Look for time-dependent and race condition problems.
Does the bug occur only at a certain time of day?
Maybe it depends on how quickly you enter the data or the fact that you're saving data to a slower floppy instead of a fast hard drive.
Was the network busy when you saw the bug? Try your test case on slower or faster hardware.
Thinking time.
3. White-box issues of boundary condithion bugs, memory leaks, and data overflows can be slow to reveal themselves.
You might perform a test that causes data to be overwritten but you won't know it until you try to use that data - maybe in a later test. Bugs that don't appear after a reboot but only after running other tests are usually in this category. If this happens, look at the previous tests you've run, maybe by using some dynamic white-box techniques, to see if a bug has gone unnoticed.
4. State bugs show up only in certain states of the software.
Examples of state bugs would be ones that occur only the first time the software is run or that occur only after the first time. Maybe the bug happens only after the data was saved or before any key was pressed. State bugs may look like a time-dependent or race condition problem but you'll find that time is unimportant - it's the order in which things happen, not when they happen.
5. Consider resource dependencies and interactions with memory, network, and hardware sharing.
Does the bug occur only on a "busy" system that's running other software and communicating with other hardware? In the end, the bug may turn out to be a race condition, memory leak, or state bug that's aggravated by the software's dependency or interaction with a resource, but looking at these influences may help you isolate it.
6. Don't ignore the hardware.
Unlike software, hardware can degrade and act unpredictably. A loose card, a bad memory chip, or an overheated CPU anc cause failures that look like software bugs but really aren't. Try to reproduce your bugs on different hardware. This is especially important if you're performing configuration or compatibility testing.