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)