(first rain interview)If a tester find a bug in a system but devloper can't then what will be the best strategy for the tester?

Questions by infiant

Showing Answers 1 - 3 of 3 Answers

Sreekar

  • Oct 25th, 2006
 

Reproduce the bug take a snapshot of it and send it as an attachment.If possible give the details of the steps followed to find the bug

  Was this answer useful?  Yes

Deepak.Bhandarkar

  • Oct 26th, 2006
 

When a bug is found by a Tester and if it is not reproducable by the Developer. There are few cases as shown below which you can follow up:

1. Make sure that the description of Bug(Incident) should be proper, with the attached Screen shots.

2. The Developer if he is not able to reproduce the bug in Developer Server, you can send the Test Server url, with the bug description and necessary screen shots.

3. The Status of the bug reported should be kept as Critical if it affects Major functionality, and if it is not reproducable always can be kept as Not reproducable always.

4. If he is still not able to replicate the Bug you can call him to your desk, and try to replicate the same ( Not done in all companies).

  Was this answer useful?  Yes

Magesh19_83

  • Oct 27th, 2006
 

Hi,

   Whenever we find bugs, report that with these things to avoid "Unable to reproduce" problem in ur bugtracker.

 Build version, Data and the steps which you had done, Screenshot

 if you and ur developer using a different DB, first try to simulate the same bug in their Db. If not so, then in urs(before that you have to inform to your TL).

 thank you

  Was this answer useful?  Yes

smitha

  • Nov 15th, 2006
 

Say "intermittent fault" to any programmer and watch their face fall. The easy problems are the ones where performing a simple sequence of actions will cause the failure to occur. The programmer can then repeat those actions under closely observed test conditions and watch what happens in great detail. Too many problems simply don't work that way: there will be programs that fail once a week, or fail once in a blue moon, or never fail when you try them in
front of the programmer but always fail when you have a deadline coming up.

Most intermittent faults are not truly intermittent. Most of them have some logic somewhere. Some might occur when the machine is running out of memory, some might occur when another program tries to modify a critical file at the wrong moment, and some might occur only in the first half of every hour! (I've actually seen one of these.)

Also, if you can reproduce the bug but the programmer can't, it could very well be that their computer and your computer are different in some way and this difference is causing the problem. I had a program once whose window curled up into a little ball in the top left corner of the screen, and sat there and sulked. But it only did it on 800x600 screens; it was fine on my 1024x768 monitor.

The programmer will want to know anything you can find out about the problem. Try it on another machine, perhaps. Try it twice or three times and see how often it fails. If it goes wrong when you're doing serious work but not when you're trying to demonstrate it, it might
be long running times or large files that make it fall over. Try to remember as much detail as you can about what you were doing to it when it did fall over, and if you see any patterns, mention them. Anything you can provide has to be some help. Even if it's only
probabilistic (such as "it tends to crash more often when Emacs is running"), it might not provide direct clues to the cause of the problem, but it might help the programmer reproduce it.

Most importantly, the programmer will want to be sure of whether they're dealing with a true intermittent fault or a machine-specific fault. They will want to know lots of details about your computer, so they can work out how it differs from theirs. A lot of these details will depend on the particular program, but one thing you should definitely be ready to provide is version numbers. The version number of the program itself, and the version number of the
operating system, and probably the version numbers of any other programs that are involved in the problem.

  Was this answer useful?  Yes

The tester should attempt to reproduce the defect again.  If the problem persists, the tester should:

1) ensure developer has performed the precise test steps.

2) ensure developer is attempting to reproduce the issue in the same test environment.

3) provide additional information that will assist the developer in reproducing the issue.  This might mean entering additional details in the defect report (prerequisites, environment, additional steps, screen shots, etc.). 

4) go the developer and personally run the test on his machine.


Give your answer:

If you think the above answer is not correct, Please select a reason and add your answer below.

 

Related Answered Questions

 

Related Open Questions