I know some people think it's "a lot of working" doing QA, but it's not. If you could verify just 10 easy duplicate bugs a day, you're helping out -- a lot. As we approach Mozilla 1.0 and Netscape 6, we need to start cleaning out the bugzilla database to absolutely zero (zarro, in bugzilla terms) open or resolved bugs. When every bug in the list is verified, we can release -- but we need your help to do this!
We would be highly appreciative if you would set aside a couple of minutes each day just to "handle" ten or more bugs...by "handle" I mean triaging and confirming unconfirmed bugs, or verifying any kind of resolved bug. Once you get in the habit of doing a set number of bugs each day, it will go fast! We don't encourage, however, that the quality of your work worsen because of pressure or deadlines -- we always prefer good QA over fast QA :)
Thanks for your time in testing Mozilla!
Thanks to all of you that participated in another productive BugDay, especially all the first time participants! Looking forward to next week....
Asa
(remember when posts with mozilla were a rare thing)
Indeed, there is a lot of work left to be done before we reach Mozilla 1.0 There are going to be bugs reported in Bugzilla which do not get fixed by Mozilla 1.0 But there are going to be even more bugs left in Bugzilla after 1.0 if we don't all help out. I approach this with the idea that if a developer can write code rather than triage bugs we will move farther and faster. So I spend some time in the Bugzilla database triaging, confirming, and moving and and verifying bugs. I also spend considerable time helping others get involved in the same kinds of activity. This saves the developers time and means that they can work on more of the bugs that concern me. If you are interested in getting involved, getting more involved or helping others get involved please stop in on IRC #qa and #mozillazine and let me know. I can also be reached by email.
the community makes mozilla (and netscape6) possible. without us they will not succeed.
Asa
now at Beijing, so far away isn't it?
i report the progress of mozilla in the internet section of the site of my company--hongen oline
www.hongen.com
one of the most considerable education content provider and the BIGGEST education software provider of China.
and many eyes keep on you.
go on guys.
Sorry, my comment seems to have sparked a little confusion.
To clarify:
> There are over 5000 open browser bugs
Actually, a search for Browser and MailNews bugs, not including enhancements or bugs with RFE in the summary line, and excluding Future bugs, yielded 3578 bugs. Many of these are old and no longer exist. Some will be invalid or wontfix. Others will be dups. I'd honestly predict that about a little less than half of those 3578 bugs can be closed up one way or another (i.e., not fixed). Many of the remaining ones will need to be deferred to after the Mozilla 1.0 release. However, we can't just release the browser when there are open bugs that haven't been handled (unless we wanna pull a win2k)
> maybe it's time for a new state in >Bugzilla. Post Release or Mozilla 2.
We already have one...two, actually. The older, deprecated RESOLVED | LATER or the newer Future milestone.
>I don't think RFE's count, as you can >never get rid of these.
Well, you can get rid of them by implementing the enhancement request...but I agree that these should not be considered as bugs, hence the reason I didn't include them in my aforementioned query for open bugs.
>But I don't think Mozilla should be >released if there are any known issues >where it hasn't been decided 'a fix is >not possible for this'.
I completely agree, and I'd imagine that the rest of the QA crew would as well.
>May be I am doing something wrong, but >I need something like an hour to >verify that an unconfirmed bug is >really a duplicate.
Nope, you're absolutely right -- unconfirmed bugs are much harder. I was referring to bugs that are resolved as duplicate, but haven't yet been verified. Often, these are almost exact duplicates, and you simply need to compare the two bugs and ensure that they are, in fact, the same problem.
>Usually I write first a testcase to >narrow down the problem, attach the >testcase and then I search for a >duplicate to finish the bug.
That's a wonderful QA practice. Keep it up!
>the statement would require to spend >something like 10 hours per day in >bugzilla, that would be fun.
Welp, I'd imagine that many mozilla.org and netscape QA employees aren't too far off from that figure. But then again, they get paid.
>So I think one good dupe a day is a >good dose.
Yep, as I said, dup'ing open or unconfirmed bugs is much harder than simply verifying resolved duplicates. Do whatever is easiest and comfortable for you, the "10-a-day" was just a suggestion.
>Especially wrong dupes are bad.
Yep, as I said -- good QA is preferred over fast QA.
>About the zero bugs: I lost completely >any optimism, just count the new bugs >per day (have seen 166).
Yes, but many of these bugs fit into one of the following areas:
* Reporter is using an old build or a milestone build to report the bug, thus it's invalid (or wfm) and no longer occurs/exists.
* The bug is a duplicate.
* The bug is a trivial UI change and can be fixed easily.
* The bug is a regression, which are often quite easy to fix.
* The bug is unconfirmed, meaning it hasn't yet been confirmed by QA that it is, in fact, a bug. Many of these turn out to be invalid or wontfix bugs.
* The bug is not really a bug at all, but rather an RFE.
Together with the requirement to check in only for nsbeta2+, it makes me believe that we are lightyears away from the TeX-bugfree state, I would dream of.
>I approach this with the idea that if >a developer can write code rather than >triage bugs we will move farther and >faster.
Agreed. A developer should be able to look at a bug for the first time and have all the necessary information at his finger tips (reproduction information, talkback reports, testcases, and so forth). Every time he or she needs to triage a bug is more wasted time for the developer that shouldn't have happened if QA was around.
