In comp.os.linux.advocacy, tab
<trentallenblack@xxxxxxxxx>
wrote
on 8 Jun 2006 09:05:50 -0700
<1149782750.435774.194950@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>
> Roy Schestowitz wrote:
>> Software Squashes Bugs With Help From Users, Open Source
>>
>> ,----[ Quote ]
>> | The best software developers in the world know you can't create code
>> | without bugs -- it's just not possible. However, new open source Latest
>> | News about open source software being put to use by open source projects
>> | including Evolution, Gaim, theGimp, Gnome, Rhythmbox and others can more
>> | quickly find the worst bugs, including those that are causing hangups for
>> | most users. In turn, users can automatically report back on software
>> | quality with a program known as the Cooperative Bug Isolation Project.
>> `----
>>
>> http://www.linuxinsider.com/story/Lgc53ypL5pi1Ib/Software-Squashes-Bugs-With-Help-From-Users-Open-Source.xhtml
>
>
> Maybe they should think about QUALITY TESTING instead squashing bugs.
>
And this is done precisely how?
AFAICT, the standard development process is along the following lines:
[1] Somebody in Marketing gets a brainy idea.
[2] The brainy idea gets documented, in a vague Requirements Document.
[3] Engineering gets this document, and discusses with the brainy
idea originator, and maybe higher-ups.
[4] Everyone happily signs up for the Implementation of the idea.
[5] Engineering then chews on the idea for awhile, and produces
a working prototype.
[6] The prototype is released to Quality Assurance, along with the
Requirements Document and a Functional Specification.
[7] QA generates a Test Specification. (Or perhaps Engineering does.)
[8] QA follows the Test Specification and generates a number of
defect reports, which are passed back to engineering.
[9] Engineering modifies the prototype and the process
goes back to step 6, or continues.
[10] QA cuts the software for release.
[11] The released software goes into the distribution chain, which could
be as simple as a website or as complicated as a mastering system
which ultimately stamps out CDs and boxes by the thousands.
I don't know the details at this point.
[12] Users start using the software.
[13] Users find bugs.
[14] Users call Customer Support.
[15] Customer Support forwards bugs back to Engineering,
Marketing, or QA. If Engineering, go back to
step 5. If Marketing, go back to step 1. If QA,
go back to step 7 for possible retesting and maybe
another iteration loop (e.g., the product might have
been designed for one file format but another file
format might need testing, subtly different from the
original but not quite enough to require a revision
to the product).
Ideally, QA would get involved much earlier in the process,
initiating a Test Specification at about the same time
Engineering starts step [5]. But I for one doubt most
departments work that way. :-) Besides, several iterations
of the [5]-[9] loop could burn out/confuse just about
everybody if document control isn't rigorously practiced.
In Freeware, [15] could include suggested code changes as
well as bugs, or one can use an entirely different build
model, or a hybrid of the two.
[3'] The Requirements Document is published on a website,
along with registration instructions for code
modifications using Subversion or CVS. Anyone can
read the code anonymously, and use it for building
the prototype on their own equipment -- once it's
past a certain point. Developers can modify and
check in changes. The Requirements Document can
also be placed into Subversion or CVS, as well,
and probably should be.
[4'] Developers have at it, and are encouraged to check
in on an occasional basis. Observers might also
participate by posting comments, suggested patches,
and discussion issues to a wiki. At this point,
QA watches the magic happen. :-)
[5'] A "nightly build machine matrix" is started up at some
point, if the corporation is willing and the
code repository is ready enough to at least build
something. All this does is loop, trying to build
the product. If the loop succeeds, the fact is
recorded and the Subversion/CVS build that succeeded
is tagged. If the build fails, the fact is recorded,
the build may be tagged (so that developers can find
the problem) and E-mails sent to anyone interested,
which is usually a developer mailing list. These are
the so-called "nightly builds".
[6'] At some point, code coverage tools and automated
testing tools are added to the build scripts.
Progress thereof is detailed on another website.
Other possibilities include automatic document
generation tools using comments in the code.
[7'] At some point, a final review of whatever got into
the code repository is done. I'm not sure what form
this would take but the most likely method would
simply be ensuring that the tests are appropriate,
the basic Requirements are met, and the tool meets
certain guidelines for portability and/or usability
that might be published somewhere else (e.g., code
coverage is almost 100%, all config options are
documented, no swear words or full frontal nudity
exist in the code, etc.).
[8'] QA cuts the software for release, and goes on to step [11] in the
original flow.
I'd have to look to see exactly how Mozilla managed the
process but this would probably work reasonably well.
The modified process is far more open, although that may
have competitive ramifications if the company isn't careful
(e.g., Company A starts developing a new whizbang game
editor thingy but Company B nabs the entire source base
and, with more "development horsepower", publishes first).
--
#191, ewill3@xxxxxxxxxxxxx
Windows Vista. Because it's time to refresh your hardware. Trust us.
|
|
