[MUD-Dev] Quality Testing

[Dave Rickey]

-----Original Message-----
From: Michael Tresca <talien at toast.net>

> It's entirely possible to have a rigorous, useful QA process.  It is
> also entirely possible to have an effective team without a QA
> process.  Neither are absolutes.

I'd agree with that statement, with some caveats.  MMOG's represent
huge and complex featuresets, and have an extremely low tolerance
for error.  This leads to a *lot* of bug reports, many duplicates
(but what is a duplicate will not neccessarily be obvious).  In a
rigorous QA process, every bug report generates it's own overhead,
as does every feature element.

More than that, a truly rigorous QA process may simply be
impossible.  Richard Garriott commented in a 97 interview that the
testing regime (instructions to the internal QA team on what to
check out) for UO filled several large 3-ring binders, thousands of
pages.  And every time features changed, that regime had to be
revised.

Well, in the course of Beta, the featureset of a MMOG is likely to
change several times.  No matter how complete you *thought* your
original design was, odds are that about half of it is either going
to change dramatically, and then there will be all the things that
become obvious "next steps" once you actually see the system in
action.

It was suspected (by those testers who were also in IT) that when EA
gave the order to ship UO that they were essentially "kicking it out
the door".  QA was telling them that to properly test just what was
in front of them in October 97 was going to take until mid 98 or
later, if nothing changed in the meantime.  EA wasn't willing to
keep funding it, so the game had to go to the stores or be tanked
completely.  Just a theory, but one that fits.

I wasn't kidding when I said that if Camelot hadn't been made by a
team of 30, it would have needed over 100.  That's if it could be
done at all, the way that traditional QA would have slowed down the
revision cycle might have made it literally impossible to *ever*
release it (by stretching out development to the point that by the
time the original design was ready, it was outdated).  We ran a
turnover cycle (concept to code to content) *daily* at some points.
In a traditional QA approach, it could have taken a week just to
figure out how something was going to be documented.

But Michael is totally correct, such a development approach demands
that everyone on the team act like a mature, responsible adult, with
no agenda beyond getting the game out and making it good.

--Dave Rickey

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev