[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: the logistics of beta release management

i didn't mean to turn this into such an issue, but what
the heck ...

On Fri, 10 Jan 2003, Michael Schwendt wrote:

> Hash: SHA1
> On Thu, 9 Jan 2003 12:59:10 -0500 (EST), Robert P. J. Day wrote:
> > let me put it another way -- once a new beta comes out, in 
> > an *ideal* world, anyone who was interested in being a beta
> > tester would drop that older version completely, and move
> > on to the new version.
> Yes. And the ideal beta tester would go through his list of reports
> one by one and close all bugs that are no longer reproducible.

i'll take issue (sort of) with this contention for the following
reason.  i claim that *my* ideal world is the one that is the
best approach for beta testing.  after a company accepts a slew
of bug reports, fixes/patches/resolves as many of them as they
think are appropriate and releases a newer beta, there is no
discernible value (IMHO) for any testing or bug reports against
the earlier beta.  given that those bugs may not exist in the
newer beta, all those bug reports are doing is potentially
clogging up the database.

if someone is willing to go to the trouble to be a responsible
and productive beta tester, and take the time to file bug reports,
it's not unreasonable to ask them to at least do this against
the latest beta.

however, there is a limit to what beta testers should be asked
to do, and i think asking them to go through their list of 
previous reports and close them if they're resolved is *way*
beyond the call of duty.

from my perspective, good beta testers should be prepared to
test things, locate bugs, isolate as much as possible the
bug, write it up, and submit it -- that's bug "reporting".

now, bringing forward unresolved bugs in the data base --
*that's* bug resolution and management, and *that's* the
responsibility of the vendor.

when a new beta comes out, i'm more than willing to download
it, install it, test the crap out of it, and report, as
accurately as i can, any bugs i find.  i'm definitely *not*
willing to spend my time sitting down with all my old bugs,
testing them again, *unless* it's a feature i'm particularly
interested in.  and if it's still broken, my plan would be
to submit a brand new bug report, period.

i'm willing to invest time in finding and reporting bugs.
i'm *not* willing to re-review all my old bug reports and
do bug management.  i don't consider that my job.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]