tag:blogger.com,1999:blog-1695460650467928609.post5563431607947258326..comments2024-03-28T01:27:39.788-07:00Comments on Software Testing Tricks: 10 Tips to Avoid Writing a Bad Software Defect Report!Debasis Pradhanhttp://www.blogger.com/profile/15059356907987625705noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1695460650467928609.post-4424768758725785322013-12-02T21:58:12.580-08:002013-12-02T21:58:12.580-08:00These are great tips in writing an effective bug r...These are great tips in writing an effective bug report. Those who are tasked to do so are surely grateful of these strategies. Thank yu for sharing. Zora Ferrelhttp://www.cloudstaff.com/noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-39053773029722102542013-02-27T06:38:43.575-08:002013-02-27T06:38:43.575-08:00Hi
I'm working as Testing engineer in middle l...Hi<br />I'm working as Testing engineer in middle level company.I need a free bug Tracking Tool .Can anyone please guide me.p.pradeepit@gmail.comPradeepIThttps://www.blogger.com/profile/10675374861694320172noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-2488741696779740672010-07-21T00:43:59.718-07:002010-07-21T00:43:59.718-07:00Interesting read and interesting comments.
I agre...Interesting read and interesting comments.<br /><br />I agree with Srini about 'selling your bug'!<br /><br />Here are two more ways you can make your defect report stand out from the crowd, and enhance its chances of getting fixed.<br />1. Make a business case.<br />2. “Show”, don’t “tell”.<br /><br />Intrigued? Read http://www.effectivesoftwaretestingblog.com/2010/06/make-your-defect-reports-stand-out-in.html to know more.<br /><br />Happy reporting!<br />~VaradaVaradahttp://www.effectivesoftwaretestingblog.comnoreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-81644526119572303782008-08-21T06:46:00.000-07:002008-08-21T06:46:00.000-07:00I think these r the confusing terminologies and co...I think these r the confusing terminologies and context you and shrini where telling in some other post in the blog.any way nice post and thanks to shrini too<BR/><BR/>Regards,<BR/><BR/>rajiRajasrihttps://www.blogger.com/profile/06228479553598417027noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-33682796548532455082007-12-17T02:56:00.000-08:002007-12-17T02:56:00.000-08:00@ Shrini,First of all let me express my happiness ...@ Shrini,<BR/><BR/>First of all let me express my happiness to see your comment on my blog post! It is a privilege to be commented by testers like you and hence thanks.<BR/><BR/>1. I use "bug" and "defect" almost synonymously in my blog posts. Having said that, I understand that "bug" is a rather wider term that covers anything that has potential to "bug" someone, who matters in a software project [I owe this understanding to James Bach and Michael Bolton]. A software "bug" need not have to be a software "defect". There are different views and opinions on using the terminologies bugs and defects. So to avoid confusion, I prefer using "bug" and "defect" synonymously as of this point of time. However, I am curious to hear your definitions of bug/defect. Are they same in your definitions. If not, would you mind sharing your definitions for these two terms. I am interested to learn your definitions.<BR/><BR/>2. #4 says a defect report should be clear and precise and #5 says tell stories to show defects. I am extremely sorry if they sounded contradicting. It must be my mistake to convey my point correctly here. Anyway, please let me clarify. When I say tell stories, I actually mean to include scenarios where this defect can be most devastating and result in most severe consequences. <BR/><BR/>Thanks for including your points to write a good and effective defect report. e.g. Isolating the defect is very very important. If the defect can be reproduced using 7 minimum steps, it is always good to keep them 7. Discarding the unnecessary steps from the defect report requires some analysis and can result in a light-weight defect report, which is easier to scan and reproduce by the programmer. <BR/><BR/>Thanks once again for spending your time reading and commenting on the post. Happy Testing...<BR/><BR/>-Debasis.Debasis Pradhanhttps://www.blogger.com/profile/15059356907987625705noreply@blogger.comtag:blogger.com,1999:blog-1695460650467928609.post-9605932821801267082007-12-17T02:04:00.000-08:002007-12-17T02:04:00.000-08:00I have few observations –1. You have not included ...I have few observations –<BR/><BR/>1. You have not included definition of “bug” or defect… What is your definition of bug/defect? Is bug same as defect?<BR/>2. Point # 4 says that defect report needs to be clear and precise. Point # 6 says, tell a story to describe a bug. I see that these two contradict. A short, precise statement is about objectivity where story telling has mostly been narration of personal experience. Story is often descriptive. An example of precise (as close as it can get) is a court order or a Law or a legal document – these can not be in a story format. When you tell a story, you leave some aspects of narration to “manipulation” and interpretation.<BR/><BR/>Here are few points that you might want to add to your 10 points – extend them:<BR/><BR/>1. Know your audience – who is reading/fixing/verifying the bugs. Write the bug report so that they understand and appreciate the report<BR/>2. Sell your bug- According to Dr Cem Kaner’s famous article “Bug advocacy”, a best tester is one who gets most bugs gets fixed. Bug report is like an “ad” – make the report so attractive that developers pick the bug for fixing without much hesitation. Make the bug and its effects more explicit. Motivate the buyer of the bug.<BR/>3. Clearly Isolate the bug - The list of steps to reproduce – has to be “bare” minimum. Smaller the number of steps better is the defect report. One way to create “slim” report is to write all that you did for getting the defect then go on removing one or more steps to see if the defect still appears. In other words, from a defect report containing 15 steps to reproduce, iterate through steps each time removing one step to see if defect still appears. There are two advantages of this approach. One, you will exactly (to best of your abilities) know the steps (and the sequence) that causes the defect. Second, while iterating, you might also discover other related bugs.<BR/>4. Don’t make the defect report big and complex. That will give developer an excuse not to fix the bug.<BR/>5. Don’t stop at bug, poke around the bug (bugs live in colonies, they come and go together) and describe various effects of the bug.<BR/>6. Help the developer – report a bug as you report “missing thing”. Provide all related information so that developer is better equipped with isolate and fix the bug.<BR/>7. Differentiate between “bug” and “its manifestations” – cause and effect.Shrini Kulkarnihttps://www.blogger.com/profile/10782753752478547381noreply@blogger.com