Each organization has its own philosophy and expectations on how much the tester is required to isolate the problem. Regardless of what is required, a tester should always invest some reasonable amount of effort into isolating the problem. Consider the following when isolating problems. .
Try to find the shortest, simplest set of the steps required to isolating the problem.
Ask yourself if anything external to the specific code being tested contributed to the problem. For example, if you experience a hang or delay, could it have been due to a network problem? If you are doing end-to-end testing can you tell which component along the way had
the failure?
Are there some things you could do to help narrow down which component had the failure?
. If your test has multiple input conditions, vary the inputs until you can find which one with which
values triggered the problem.
In the problem description, to the extent possible, describe the exact inputs used. For example, if you found a problem while printing a Postscript document, even if you think the problem occurs with any Postscript document, specify the exact document that you used to find the problem.
Your ability to isolate, in large part, defines your value-add as a tester. Effective isolation saves everyone along the line a great deal of time. It also saves you a lot of time when you have to verify a fix.
