Discussion: What about the tS7 proteam beta?? Is it ready? 2005-02-10 - By Allen Cobb
Back
Just adding my 2 cents for Roman, et al (not sure why, but maybe
you folks will find it interesting)...
I've written a lot of sw, and participated in a lot of betas --
there really is a surprising amount to consider before releasing
a beta, even to such an experienced and receptive crowd as
Pro-Team, so I thought I'd toss in some reflections on beta
testing in general. I hope this will help some of the group have
a better understanding of what Roman and his team are dealing
with.
Test versions often come in three stages -- alpha, beta, and
release candidate.
The alpha version is rough, full of holes, missing functions,
tentative features that may disappear, etc. It's really not for
"testers" to test at all -- just for the developers to kick
around and see how the whole thing is coming together.
The beta stage means that the app is functionally very close to
what will be released -- otherwise there's not much point in
testing it. Every change or fix you introduce has to be
re-tested (!), so the beta has to be at the point where you are
no longer making significant changes. (That doesn't preclude
making a "demo" version to get people's reactions, but in my
experience, demo's generally cause a lot of confusion and
headache.)
The release candidate version is supposed to be finished. Truly
finished. But since life is full of surprises, you test the
finished version anyway, and you always find a few more bugs.
Perhaps the biggest difference between a beta version and a
release candidate is that the beta is still KNOWN to have bugs,
and help is needed to find them -- specifically, help from
sympathetic and systematic testers with experience in using the
program. The release candidate, on the other hand, is SUPPOSED
to be ready for prime time, and should be trouble-free for
people who aren't really testers, including first-time users,
people with strange computing environments, etc.
So the beta is a special critter -- it's nearly done, but still
needs work. It needs to be tested, but not by the general
public. But it needs to work very closely to the finished
product, or the beta will have to be done over and over again.
A critical factor for beta testers is the app's overall
stability. As a program nears the beta stage, it is likely to
contain lots of testing and diagnostic code, which can slow the
app down, and add significant confusion for anyone testing the
new app for the first time. If testers are confronted with lots
of crashing and diagnostics, the process can become very
frustrating and unproductive -- which means the app doesn't
really get tested the way it should. Worse yet, if the beta is
released with bugs and glitches that are already known, then the
testers end up wasting a lot of time reporting things
unnecessarily. So you've got to squash all the known bugs (and
re-test in-house) before you can do a beta.
So Roman isn't just tweaking and polishing -- he's saving us a
lot of work, and saving his team a lot of redundant feedback.
It's a judgement call, when to finally let the baby out of the
playpen, but he's the only one who can take all the factors into
consideration and ensure that the beta project itself will
really help move the application towards perfection.
ac
Allen Cobb
a@(protected)
www.acobb.com
www.timbreproductions.com
|
|
