Path: utzoo!mnetor!uunet!husc6!hao!ames!pasteur!ucbvax!USU.BITNET!SLMYQ
From: SLMYQ@USU.BITNET
Newsgroups: comp.sys.amiga
Subject: Ideas for testing programs for the "USENET Seal of Approval"
Message-ID: <8803160346.AA02852@jade.berkeley.edu>
Date: 16 Mar 88 02:39:00 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 72

Here are a few ideas for testing programs for the "Usenet seal of approval".

    o How many bugs are there?

    o How smoothly does it run?

    o How consistent is it?

    o Does it offer on-line help?

    o How much does it use Intuition?

    o Does it offer command-keys for often-used menus?

    o Does it use menus?

    o Check what the program does if you run it in an operating system
      version it wasn't made for. (Like run a 1.2 program in 1.1.)

    o Does it use RMBTRAP if there are no menus?

    o When it needs to abort (such as not enough memory), does it tell
      you what happened, or does it just quit?

    o Check the error recovery:  if it can't open something, does it
      close everything it already opened?

    o For cutting and pasting, does it use the clipboard device AND
      stick to IFF?

    o For that matter, does it use IFF?

    o CLI programs: does it check for CTRL-C's?

    o Mostly for games - does it take over the machine without it
      being absolutely necessary?

    o When it puts up an autorequester, click in its normal window and
      click the menu button.  Many programs which use MENUVERIFY and
      also use AutoRequests (or DOS) forget to clear MENUVERIFY when
      they put up an autorequester.

Additional test might be possible if the author is willing to give the
testers (sp?) the source code.  This way, the program could be even
better approved. (USENET Source Approval?)  Good source code helps to
keep the hard-to-find bugs out of a program.

    o How modular is the program?  Does it look like it was built or
      does it look like it just "happened"? :)

    o How many global variables does it use?  They can be a real pain
      debugging, and as a result may produce more bugs.

Anyway, these are a few to munch on.  See if you Usenet-ites can add
more.

As for the testers, I think (1) there should always be several to keep
personal preferences down, and (2) they should NOT be hackers.  They
should be "normal" Amiga users that don't know anything about programming.
Hackers tend to prefer control sequences, complex command sequences,
and a command line interface.  I'm not anti-hacker, since I *am* one,
but I think the hackers should make programs for non-hackers as well
as fellow hackers.


                                    Bryan

       Bryan Ford             \\                                     //
Snail: 1790 East 1400 North    \\ "Copy" may be a four-letter word, //
       Logan, UT 84321          \\          but who cares?         //
Email: USU@FATQW.BITNET          \\ //                         \\ //
Phone: (801)753-1159              \X/           -me             \X/