Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!decvax!decwrl!sun!steinmetz!davidsen@steinmetz.
From: davidsen@steinmetz.
Newsgroups: comp.text.desktop
Subject: Re: How to run a Beta Test
Message-ID: <24233@sun.uucp>
Date: Mon, 27-Jul-87 14:14:30 EDT
Article-I.D.: sun.24233
Posted: Mon Jul 27 14:14:30 1987
Date-Received: Tue, 28-Jul-87 07:30:17 EDT
Sender: news@sun.uucp
Reply-To: kbsvax.steinmetz!davidsen@uunet.UU.NET (William E. Davidsen Jr)
Distribution: comp
Organization: General Electric CRD, Schenectady, NY
Lines: 49
Approved: desktop-request%plaid@sun.com

In article <23056@sun.uucp> news@sun.uucp (news) writes:
|o Build up a prospective list of your customers and whoever else you
|    know that might qualify.  Pass that list around the company and get
|    feedback, especially from the developers, and support groups.  If
|    anyone on the list is flagged as a problem customer, get them off
|    the list (this means if ONE person flags them -- blackballs are
|    appropriate). You want customers who are working with and for you
|    -- and only those people.

Having done beta testing and early release programs for INteractive,
IBM, Solution Systems and Microsoft, I disagree. Technical support may
hate someone because "that SOB is *always* calling with problems." If
they are legitimate problems in the product or documentation you
probably want this guy. You should be selecting on the basis of ability
to find, replicate, and report problems, not on what a nice guy s/he is.

The good beta testers are either totally incompetent, beginners, or have
devious minds. I once had a vendor tell me that I could "find failure
modes in a bowling ball." I *hope* that was a complement.

|o Part of the beta agreement is an agreement to do a weekly written
|    report.  Every beta tester will send in a weekly report of problems
|    and comments, or a piece of paper that says "nothing sigificant
|    found" or full of recipes or something.  They should also have a
|    contact in the company to call as soon as a problem is found, but
|    the written report is backup that something didn't get dropped on
|    the floor.  It is also a good check that the beta tester is beta
|    testing. If they miss two reports, pull the software or get a good
|    reason.

I hope you intended to include email "written reports". I have used them
now, and I think they are much better than paper, because the tester can
easily include a code fragment with a report.
===
I agree with the rest of what you said (or at least don't disagree).
Thanks for sharing this with us, I suspect many people have never had a
guidance in this area.

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
----------------------------------------
Submissions to:   desktop%plaid@sun.com -OR- sun!plaid!desktop
Administrivia to: desktop-request%plaid@sun.com -OR- sun!plaid!desktop-request
Paths:  {ihnp4,decwrl,hplabs,seismo,ucbvax}!sun
Chuq Von Rospach	chuq@sun.COM		Delphi: CHUQ

We live and learn, but not the wiser grow -- John Pomfret (1667-1703)