Topic: When the bug is fixed, more or less.

Message

   The boomerang returns...In many organizations, the people 
who file bug reports are asked to verify the fix when the fix is completed. Or 
you may be testing the fix for a bug someone else submitted. My goal is to 
complete this step with at least as many bugs open as when I started. 

< ="text/">
  GA_googleFillSlot("OneStopTesting-MidBanner");
< ="http://pubads.g.doubleclick.net/gampad/ads?correlator=1248761922162&output=json_&callback=GA_googleSetAdContentsBySlotForSync&impl=s&prev_afc=3&a2ids=%2C&cids=%2C&client=ca-pub-4686307991865625&slotname=OneStopTesting-MidBanner&page_slots=OneStopTesting-TopBanner%2COneStopTesting-TopBanner-2%2COneStopTesting-MidBanner&cust_s=&=ID%3D7dd361fe3ac66ba1%3AT%3D1247226631%3AS%3DALNI_Ma2tB91sIdK7G1mpvWPR5KbMEhBzg&ga_vid=1593024232.1247226630&ga_sid=1248761895&ga_hid=1265198909&ga_fc=true&url=http%3A%2F%2Fwww.onestoptesting.com%2Farticles%2Fbug-re%2Fbug-fixed.asp&ref=http%3A%2F%2Fwww.onestoptesting.com%2Farticles%2Fbug-re%2F&lmt=1248761922&dt=1248761927674&cc=20&u_h=768&u_w=1024&u_ah=738&u_aw=1024&u_cd=32&u_tz=330&u_his=50&u_java=true&u_nplug=13&u_nmime=54&flash=10.0.12">

Of course, you should try to reproduce the bug the way you originally reported 
it. Sometimes, the problem is still there, as if nothing at all was fixed. 
Perhaps because of a configuration management glitch, the fix isn't in the build 
you have. Or maybe there's something specific about my configuration that I 
either didn't report or the programmer didn't think was significant. When I 
reject a bug fix outright, I try to include additional details about my 
configuration and exactly how I reproduced the bug. I use different wording than 
I did the first time around to help reduce any misunderstanding. And I write 
with a tone that expresses puzzlement rather than condemnation. In almost all 
cases, the programmer really did make an effort to fix the bug, and we need to 
recognize that effort. 

What if the fix did some good but doesn't address the bug to your satisfaction? 
You have a judgement call to make. If the changes to the software represent some 
sort of progress, and can stand alone if no further improvements are made, then 
I recommend closing the bug as fixed. I don't like keeping a bug report open for 
a long time, spawning many changes, and possibly changing its focus several 
times.  

Open one or more new bug reports, describing the additional changes you would 
like to see. Doing this before closing the existing bug will help make sure you 
don't get distracted and forget to follow up, and it will give you the ID 
numbers for the new bugs that you can reference in the comments when you close 
out the old report. It's good to leave a trail between related bugs. 

On the other hand, if the fix is really unfinished, go ahead and reject it; send 
the bug back to the programmer. Maybe an obvious new bug was introduced, or some 
small detail was overlooked. It would be easier for the programmer to clean 
things up while the code is still fresh on her mind than to wait for a new bug 
report to filter through the system. Deciding whether to reject a fix or file a 
new bug report is often a tough one, but if you have developed a good working 
relationship
 with the programmers, you'll get a good result either way. 

Author	Message
Mithi25 Senior Member Joined: 23Jun2009 Online Status: Offline Posts: 288	Topic: When the bug is fixed, more or less. Posted: 28Jul2009 at 12:23am
	The boomerang returns...In many organizations, the people who file bug reports are asked to verify the fix when the fix is completed. Or you may be testing the fix for a bug someone else submitted. My goal is to complete this step with at least as many bugs open as when I started. < ="text/"> GA_googleFillSlot("OneStopTesting-MidBanner"); < ="http://pubads.g.doubleclick.net/gampad/ads?correlator=1248761922162&output=json_&callback=GA_googleSetAdContentsBySlotForSync&impl=s&prev_afc=3&a2ids=%2C&cids=%2C&client=ca-pub-4686307991865625&slotname=OneStopTesting-MidBanner&page_slots=OneStopTesting-TopBanner%2COneStopTesting-TopBanner-2%2COneStopTesting-MidBanner&cust_s=&=ID%3D7dd361fe3ac66ba1%3AT%3D1247226631%3AS%3DALNI_Ma2tB91sIdK7G1mpvWPR5KbMEhBzg&ga_vid=1593024232.1247226630&ga_sid=1248761895&ga_hid=1265198909&ga_fc=true&url=http%3A%2F%2Fwww.onestoptesting.com%2Farticles%2Fbug-re%2Fbug-fixed.asp&ref=http%3A%2F%2Fwww.onestoptesting.com%2Farticles%2Fbug-re%2F&lmt=1248761922&dt=1248761927674&cc=20&u_h=768&u_w=1024&u_ah=738&u_aw=1024&u_cd=32&u_tz=330&u_his=50&u_java=true&u_nplug=13&u_nmime=54&flash=10.0.12"> Of course, you should try to reproduce the bug the way you originally reported it. Sometimes, the problem is still there, as if nothing at all was fixed. Perhaps because of a configuration management glitch, the fix isn't in the build you have. Or maybe there's something specific about my configuration that I either didn't report or the programmer didn't think was significant. When I reject a bug fix outright, I try to include additional details about my configuration and exactly how I reproduced the bug. I use different wording than I did the first time around to help reduce any misunderstanding. And I write with a tone that expresses puzzlement rather than condemnation. In almost all cases, the programmer really did make an effort to fix the bug, and we need to recognize that effort. What if the fix did some good but doesn't address the bug to your satisfaction? You have a judgement call to make. If the changes to the software represent some sort of progress, and can stand alone if no further improvements are made, then I recommend closing the bug as fixed. I don't like keeping a bug report open for a long time, spawning many changes, and possibly changing its focus several times. Open one or more new bug reports, describing the additional changes you would like to see. Doing this before closing the existing bug will help make sure you don't get distracted and forget to follow up, and it will give you the ID numbers for the new bugs that you can reference in the comments when you close out the old report. It's good to leave a trail between related bugs. On the other hand, if the fix is really unfinished, go ahead and reject it; send the bug back to the programmer. Maybe an obvious new bug was introduced, or some small detail was overlooked. It would be easier for the programmer to clean things up while the code is still fresh on her mind than to wait for a new bug report to filter through the system. Deciding whether to reject a fix or file a new bug report is often a tough one, but if you have developed a good working relationship with the programmers, you'll get a good result either way.
	Send Unlimited FREE SMS to Any Mobile Anywhere in INDIA, Click Here Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged

cool7575 Newbie Joined: 13Sep2007 Online Status: Offline Posts: 28	Posted: 30Jul2009 at 3:24am
	it depends on the project contract and severity of the defect. You cannot send a defect to UAT with is critical. Also you cannot fix all the defects before UAT if it is a big application. Thanks Software Testing
	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Bug Report @ OneStopTesting