Comments on: Standardised Bug Reporting with SEERS http://zeroedandnoughted.com/standardised-bug-reporting-with-seers/ 0000000000000000000000000000000000 Tue, 05 Jul 2011 12:09:22 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: ManuelFE http://zeroedandnoughted.com/standardised-bug-reporting-with-seers/#comment-6488 ManuelFE Mon, 27 Jun 2011 18:47:33 +0000 http://www.zeroedandnoughted.com/?p=197#comment-6488 Hello. Please upon to my neighbourhood )) Hello.
Please upon to my neighbourhood ))

]]> By: Alun http://zeroedandnoughted.com/standardised-bug-reporting-with-seers/#comment-42 Alun Tue, 13 Oct 2009 22:55:23 +0000 http://www.zeroedandnoughted.com/?p=197#comment-42 Oh, I don't think I explained the bit about time correctly. The reason I find time important sometimes is that if it is a server side bug I can then look for a stacktrace or load figures in the server logs to try and determine what the issue is. I don't know the screencasting tool that has been used in the past I am afraid as I was receiving, rather than raising the bugs. This one sounds ok though: http://camstudio.org Oh, I don’t think I explained the bit about time correctly. The reason I find time important sometimes is that if it is a server side bug I can then look for a stacktrace or load figures in the server logs to try and determine what the issue is.

I don’t know the screencasting tool that has been used in the past I am afraid as I was receiving, rather than raising the bugs. This one sounds ok though: http://camstudio.org

]]> By: booshtukka http://zeroedandnoughted.com/standardised-bug-reporting-with-seers/#comment-41 booshtukka Thu, 08 Oct 2009 18:41:37 +0000 http://www.zeroedandnoughted.com/?p=197#comment-41 Whilst I agree in principal on the addition of screencasts, there is a clear cost in time and effort implementing this with it rarely being beneficial. Often, an annotated screenshot will be enough to get this theme of point across. That said, I have included it under the Screenshot section, as there will be occurrences where this is the clearest way to demonstrate a bug. Do you recommend a piece of software for capturing these? I have not seen anything that lets you annotate them in a clear way. Capturing the time is a good idea too, but again something that is only going to be useful on rare occasions. Still, if the error only occurs at a specific time/date/interval, it is going to be very hard to recreate consistently and so I agree it would help. The severity can certainly be subjective, but including clear (as much as is possible) definitions and examples as I have done helps to stop every bug being raised as Blocker or Critical, which is often the case. Where I have implemented SEERS, it is because the testing team do not include enough accurate details in their bug reports, and so I have tried very hard to keep it down to a small list of guidelines that are easy to follow, and therefore likely to be followed. While I agree with both of your points, and have added them to the post, I do not think they merit their own heading. Also, it would spoil my acronym. :) I hope you can use this is of help to you your next project. Thanks for the comments, Alun! Whilst I agree in principal on the addition of screencasts, there is a clear cost in time and effort implementing this with it rarely being beneficial. Often, an annotated screenshot will be enough to get this theme of point across. That said, I have included it under the Screenshot section, as there will be occurrences where this is the clearest way to demonstrate a bug. Do you recommend a piece of software for capturing these? I have not seen anything that lets you annotate them in a clear way.

Capturing the time is a good idea too, but again something that is only going to be useful on rare occasions. Still, if the error only occurs at a specific time/date/interval, it is going to be very hard to recreate consistently and so I agree it would help.

The severity can certainly be subjective, but including clear (as much as is possible) definitions and examples as I have done helps to stop every bug being raised as Blocker or Critical, which is often the case.

Where I have implemented SEERS, it is because the testing team do not include enough accurate details in their bug reports, and so I have tried very hard to keep it down to a small list of guidelines that are easy to follow, and therefore likely to be followed. While I agree with both of your points, and have added them to the post, I do not think they merit their own heading. Also, it would spoil my acronym. :)

I hope you can use this is of help to you your next project. Thanks for the comments, Alun!

]]> By: Alun http://zeroedandnoughted.com/standardised-bug-reporting-with-seers/#comment-40 Alun Thu, 08 Oct 2009 08:53:05 +0000 http://www.zeroedandnoughted.com/?p=197#comment-40 Sounds like a great idea. Only comments are that the addition of screencasts can really make it easier to understand behavioural bugs (rather than just screenshots) and a comment that severity can be subjective unless the people creating the bugs have a good idea of what the business goals and timelines are for a release/project. Also important to capture is the time that the bug occurred (to the second if possible) especially if this differs from the time that the issue is raised as this information can aid in server side debugging at a later time. Sounds like a great idea. Only comments are that the addition of screencasts can really make it easier to understand behavioural bugs (rather than just screenshots) and a comment that severity can be subjective unless the people creating the bugs have a good idea of what the business goals and timelines are for a release/project.

Also important to capture is the time that the bug occurred (to the second if possible) especially if this differs from the time that the issue is raised as this information can aid in server side debugging at a later time.

]]>