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

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).

Magesh19_83

 Profile 

• 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

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.

jainbrijesh

 Profile Answers by jainbrijesh Questions by jainbrijesh

• Dec 5th, 2006

 

Bug isolation.

mathan_vel

 Profile Answers by mathan_vel Questions by mathan_vel

• May 4th, 2009

 

1) Take Screen shot where the bug arised.
2) Clearly mention the steps for the executional bugs.
3) Clearly note down the Test data.
4) Clearly note down the Test Environment.

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Nov 19th, 2009

 

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.