Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdcad!sun!enea!luthcad!sow%luthcad.UUCP@uunet.UU.NET From: sow%luthcad.UUCP@uunet.UU.NET Newsgroups: comp.text.desktop Subject: Re: How to run a Beta Test Message-ID: <24715@sun.uucp> Date: Mon, 3-Aug-87 11:46:44 EDT Article-I.D.: sun.24715 Posted: Mon Aug 3 11:46:44 1987 Date-Received: Tue, 4-Aug-87 05:14:08 EDT Sender: news@sun.uucp Reply-To: enea!luthcad.local!sow%luthcad.UUCP@uunet.UU.NET (Sven-Ove Westberg) Distribution: comp Organization: University of Lulea, Sweden Lines: 68 Approved: desktop-request%plaid@sun.com >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. I disagree, you need people who have problems with your products. If they have problems you have to find the reason. Perhaps they just run other applications on the system then you do. Which perhaps results in that they run into new bugs. We are a beta test site and I one of the nasty guys who always run into problems. But they offered us to be a beta test site in spite of me. You also need some new beta testers each time, sice the old one runs the same tests as last time. I presume that the developers learns something from the history. By the way have you tested "sed -e" on a Sun??? :-) >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. You talk about the beta testers dutys. But you should also send reports back to the beta tester about the current status, containing fixed, remaining and new bugs (all bugs not only this beta testers). We send weekly reports and got weekly reports and software updates. >o Do not scrimp on testing time. Anyone who spends a year developing a > piece of software should realize that it can't be tested in four weeks. Is it possible to settle the testing time? What do you do if you got a lot of new bugs each week when the scheduled time ends? Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. Tel: +46-920-91677 (work) +46-920-48390 (home) UUCP: sow@luthcad.UUCP or seismo!mcvax!enea!luthcad!sow ARPA: enea!luthcad!sow@seismo.css.gov [moderator's kibbitz: You misundestand my statement -- I agree with you completely that you need beta testers which have problems with your program -- but you do NOT need beta testers who ARE problems, which is what I was talking about And yes, feedback TO the beta testers is important, too, and companies are bad at this as well. But it is also more difficult unless someone is in charge of collating and distributing the material back out If you're still getting lots of new bugs when the scheduled testing time ends, you don't have a product, you have a problem. You have two choices: slip schedule and fix the thing, or ship it anyway and expect to get roasted by your customers. A pissed-off customer can easily become an ex-customer. Is it worth the risk? -- chuq] ---------------------------------------- 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)