[WG: Sakai QA] [Building Sakai] Writing good bug reports

[Corey McGarrahan]

Good article. 'Testers' need to realize that not only will developers be looking at the ticket to try to reproduce and fix the issue but that other testers will be looking at their tickets to verify those fixes. Without steps to reproduce the issue this is nearly impossible. There are many ways to exercise the functionality but usually only one way to reproduce the issue.
There are some guidelines laid out in confluence for how to create an Issue in JIRA, I think it would be a good idea for anyone who plans on testing to review this before beginning. Also, this may not be the best place for the info in the first place, maybe it should be broken out and highlighted?

>From http://confluence.sakaiproject.org/display/QA/QA+How+To
"10. Write a verbose description for the issue in the 'Description' text box. This should usually include a very detailed analysis of the situation. Giving the developers as much evidence as possible makes it easier for them to fix the problem. In most cases, you should add a step-by-step process by which a tester can reproduce the issue. Feel free to include error messages or short Java backtraces here, if appropriate."

Corey

----- Original Message -----
From: "Aaron Zeckoski" <aaronz at vt.edu>
To: "Stephen Marquard" <stephen.marquard at uct.ac.za>
Cc: sakai-qa at collab.sakaiproject.org, sakai-dev at collab.sakaiproject.org
Sent: Wednesday, July 22, 2009 1:03:24 AM GMT -07:00 U.S. Mountain Time (Arizona)
Subject: Re: [Building Sakai] Writing good bug reports

I don't agree with the perception of testers in the article (as
negative to the process) but I definitely agree that good bug reports
and feature requests are critical. I cannot tell you the number of
times I have been assigned bug reports and feature requests with a
single sentence as the only description but it happens often (far more
than it should).

-AZ

On Wed, Jul 22, 2009 at 7:53 AM, Stephen
Marquard<stephen.marquard at uct.ac.za> wrote:
> Here's a good, short article on writing good bug reports:
>
> http://blog.utest.com/respect-the-defect-advice-that-will-change-the-perception-of-qa/2009/06/
>
> Summary: when describing a bug, include the steps to reproduce, a "reference point as to why something is a defect" and the "loss of value to a stakeholder (usually an end-user)".
>
> Cheers
> Stephen
>
>
>
> Stephen Marquard, Learning Technologies Co-ordinator
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za
> Email/IM/XMPP: stephen.marquard at uct.ac.za
> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>



-- 
Aaron Zeckoski (azeckoski (at) vt.edu)
Senior Research Engineer - CARET - University of Cambridge
https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"