🚀 go-pugleaf

>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)