tag:blogger.com,1999:blog-3806208351698608392.post1308445806271281971..comments2023-10-28T16:37:34.195+05:30Comments on Software Testing Space: Bug report: How to write an effective bug report?Inder P Singhhttp://www.blogger.com/profile/05923580987480854491noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-3806208351698608392.post-674577407615076362021-01-10T22:07:56.984+05:302021-01-10T22:07:56.984+05:30Hi,
is it just me or is it not possible to permane...Hi,<br />is it just me or is it not possible to permanently disable the tracking of own site visits on blogger.com?<br />There is an option in statistics but there is no "apply" button so in my case (both with Safari and Chrome) some times the own visits of my travel blog are still shown in statistics, some are not. And always after some days, the checkbox is again not selected.<br />thanksScrolan und Moritzhttps://www.blogger.com/profile/08737500854703805697noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-29057758848622828342010-05-10T15:58:56.729+05:302010-05-10T15:58:56.729+05:30Sure, Ashutosh. It commonly takes substantial time...Sure, Ashutosh. It commonly takes substantial time and resources to set up, run and analyze a stress/ load test. Even after setting up and running a stress/ load test once, no obvious performance issues may be discovered. For example, a throughput of 1 GBps may be acceptable with the given application and infrastructure.<br />When performance issues are indeed discovered, a simple bug report may not suffice (as you have rightly mentioned). The performance issue needs to be supported by the following information. Only then, can the management and the team take an informed decision whether to go ahead and expend time and resources on the issue.<br />1. Test approach used<br />2. Test environment configuration (application build used, scenarios and load used, load test tool used, run-time settings used, test run time, application technical infrastructure e.g. servers and network used and so on)<br />3. Analysis of the results (with supporting data and statistical interpretations)<br />A single (series of) test(s) may reveal one or more performance issues. Sometimes, the team doing the performance tests also undertakes performance engineering. In such a case, there might be recommendations associated with the performance issue.<br /><br />You are right. A simple bug report may not communicate all the necessary information about a performance issue. The above post is more biased towards functional bugs and not performance issues. Thanks for leaving your comment.Inder P Singhhttps://www.blogger.com/profile/05923580987480854491noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-33610123210888964682010-05-10T12:21:55.020+05:302010-05-10T12:21:55.020+05:30Hi Inder,
Dont know if it makes sense or not in b...Hi Inder,<br /><br />Dont know if it makes sense or not in bug reports but is often asked by my collegues that we should also provide information about condition that has worked specially when we are doing a stress, load testing or boundry testing<br />e.g. When i am running a traffic at 1 GBps rate i am seeing the system crashes and never recovers <br /><br />The above defect is too generic and do not give good indicator to the management whether to put resources to fix the issue and burning the time and money<br /><br />If the tester also provide information that till what condition the system works fine then it helps the management to priortise the defect easily<br /><br />Hope this is making sense<br /><br />Thanks for useful blogs <br /><br />Regards,<br />AshutoshAshutosh Chandranoreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-91537814402919181512010-03-11T17:38:32.088+05:302010-03-11T17:38:32.088+05:30Dear @Anonymous,
1. The "Title" field i...Dear @Anonymous,<br /><br />1. The "Title" field is not missing from the article :) It is just called "Summary" in it.<br /><br />2. A bug report may be rejected (wasting everyone's time) if it is not within the agreed test scope. <br /><br />Thank you for your comment!Inder P Singhhttps://www.blogger.com/profile/05923580987480854491noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-53106569856457348282009-04-05T14:05:00.000+05:302009-04-05T14:05:00.000+05:302 remarks:1 - Title - which is a very importent pa...2 remarks:<BR/><BR/>1 - Title - which is a very importent part of any report is missing from your article - especialy in large and busy forums of bug discussion - if the title does not include the essence - wrong decision will be taken!<BR/><BR/>"Ensure that the bug report is within the scope of the current test" - I could not understand that - a connection to test is nice, but if you find a defect, it's your responsibility to open a defect, or make sure someone else do so. You do have to make sure that the bug is in the scope of the project's requirments, but test scope is not a factor (except for reference use)here when submitting bug.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-3611296710513423502009-04-03T10:54:00.000+05:302009-04-03T10:54:00.000+05:30@Mark,You have given me good feedback about the co...@Mark,<BR/><BR/>You have given me good feedback about the conclusion part of my post. Additionally, I feel that the conclusion is a bit too short. <BR/><BR/>Just like you, several readers have given me good feedback about this post. I am planning to re-write the post and hope that I would be able to address your feedback in the re-write. <BR/><BR/>Thanks again and have a good day! <BR/>Inder P SinghInder P Singhhttp://www.linkedin.com/pub/9/593/816noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-7036074479962950542009-04-02T16:26:00.000+05:302009-04-02T16:26:00.000+05:30@Ankur,Thanks for pointing out Bugzilla help. Bug...@Ankur,<BR/><BR/>Thanks for pointing out Bugzilla help. Bugzilla – Bug Writing Guidelines are available at the URL, http://landfill.bugzilla.org/bugzilla-tip/page.cgi?id=bug-writing.html . <BR/><BR/>Your take on guidelines no. 2 and 5 is also okay. Your approach reduces the risk of defects being lost by not having been reported or being reported along with other similar defects. Please remember that my post is about tips on bug reporting. You should use your own professional judgement to determine which of these tips would work for you, your team, your developers, your project, your organization and your client.<BR/><BR/>Thanks for your inputs!<BR/>Inder P SinghInder P Singhhttps://www.blogger.com/profile/05923580987480854491noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-88574188658729755742009-04-02T12:35:25.114+05:302009-04-02T12:35:25.114+05:30Thanks for the post but for me it seemed to be too...Thanks for the post but for me it seemed to be too 'general', kind of guide for housewives... I suppose every person involved into testing is quite aware of all this. So may be it would be helpful to hear about some specific examples or kind of that.Katya Kamenevahttps://www.blogger.com/profile/04715330773894760209noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-34803866581162322852009-04-02T09:52:00.000+05:302009-04-02T09:52:00.000+05:30Inder, also check what bugzilla help says about bu...Inder, also check what bugzilla help says about bug reports, its what you have said and somethings more. its a nice read.<BR/><BR/>I have a different opinion on point 2 and 5 of your guidelines. As for point 2, i would like any testing engineer to report anything that he finds unacceptable as a bug. To a some extent i am OK with invalid bugs, than not reported bugs.<BR/><BR/>For point 5 coupling issues create a problem, as a page might have 6 issues, and u decide to fix 3, 2 are invalid and 1 is deferred, then that bug report management becomes messy..Ankurhttps://www.blogger.com/profile/13615850460052651146noreply@blogger.comtag:blogger.com,1999:blog-3806208351698608392.post-57653474168403988272009-04-01T21:29:00.000+05:302009-04-01T21:29:00.000+05:30As blogs go, that's quite a lot to take in at ...As blogs go, that's quite a lot to take in at one time.<BR/><BR/>I've also commented on your posting at LinkedIn QAGuild forum.<BR/><BR/>You open well. You sow the seed that this is based on experienced input, and will have hints and tips. But then you conclude by sounding pompus with "... the proper use of different fields ...". <BR/><BR/>"Proper" and "hints & tips" don't seem to sit well in the same article.<BR/><BR/>I think that it all got away from you a little here. Don't get me wrong, there is some good stuff here - but as hints and tips.MarkGilbynoreply@blogger.com