home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / PROG_GEN / BETA301.ZIP / WHYBETA.ZIP / WHYBETA.DOC
Text File  |  1994-01-03  |  37KB  |  1,047 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.                  BBBBBB    EEEEEEE   TTTTTTTT    AAAA
  7.                  BB   BB   EE        T  TT  T   AA  AA
  8.                  BBBBBB    EEEEE        TT      AAAAAA
  9.                  BB   BB   EE           TT      AA  AA
  10.                  BBBBBB    EEEEEEE      TT      AA  AA
  11.  
  12.  
  13.                   TTTTTTTT  EEEEEE  SSSSSSS   TTTTTTTT
  14.                   T  TT  T  EE      SS        T  TT  T
  15.                      TT     EEEE    SSSSSSS      TT
  16.                      TT     EE           SS      TT
  17.                      TT     EEEEEE  SSSSSSS      TT
  18.  
  19.  
  20.          PPPPP  RRRRR   OOOO   GGGGG  RRRRR   AAAA    MMM MMM
  21.          PP  PP RR  RR OO  OO GG      RR  RR AA  AA  MM  M  MM
  22.          PPPPP  RRRRR  OO  OO GG  GGG RRRRR  AAAAAA  MM  M  MM
  23.          PP     RR RR  OO  OO GG    G RR RR  AA  AA  MM  M  MM
  24.          PP     RR  RR  OOOO   GGGGG  RR  RR AA  AA  MM  M  MM
  25.  
  26.            COPYRIGHT (c) 1992-1994 , MyLife Software
  27.                - all rights reserved.
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.                        ________
  40.                    ____|__     |               (R)
  41.                 --|       |    |-------------------
  42.                   |   ----|--  |  Association of
  43.                   |  |       |_|  Shareware
  44.                   |__|   o   |    Professionals
  45.                 -----|   |   |---------------------
  46.                      |___|___|    MEMBER
  47.  
  48.  
  49.  
  50.                     Beta Test Program
  51.                     Table of Contents
  52.  
  53. Introduction.......................................... 1
  54.  
  55. What's in the package................................. 2
  56.      Manual........................................... 3
  57.      Ideas............................................ 3
  58.      Files............................................ 3
  59.      System requirments............................... 3
  60.  
  61. Quick Start........................................... 3
  62.  
  63. What's a beta test program............................ 5
  64.      Design phase..................................... 6
  65.      Alpha testing.................................... 6
  66.      Beta testing..................................... 6
  67.      What beta testing is not......................... 7
  68.  
  69. Why is a beta test program important.................. 7
  70.      Less bugs........................................ 7
  71.      Quicker application turnaround................... 8
  72.  
  73. How will a beta test program help me.................. 8
  74.      Less bugs........................................ 8
  75.      More sets of eyes................................ 8
  76.  
  77. Developing a beta program............................. 9
  78.      Items needed..................................... 9
  79.      Soliciting beta testers......................... 10
  80.      What to give to testers......................... 10
  81.      Customizing..................................... 10
  82.  
  83. Making a beta program work........................... 11
  84.      Number of beta testers.......................... 11
  85.      Different pieces................................ 11
  86.      Share the effort................................ 12
  87.  
  88. Methods of implementation............................ 12
  89.      Same testers.................................... 12
  90.      Different testers............................... 12
  91.      Specific testers................................ 13
  92.  
  93. What's in it for the beta tester..................... 13
  94.  
  95. What is BETARPT.EXE.................................. 14
  96.      Command line options............................ 14
  97.      System requirements............................. 16
  98.  
  99. Why use BETARPT.EXE.................................. 16
  100.  
  101. How will BETARPT.EXE help me......................... 18
  102.  
  103. Summary.............................................. 17
  104.  
  105. Trademarks........................................... 17
  106.  
  107.                        INTRODUCTION
  108.  
  109. Before we get started let me introduce myself. My name is 
  110. John Michael Sanders. I write custom business software and 
  111. shareware. I began my humble little business originally 
  112. called, Energy Software, in 1989. I later dissolved that 
  113. business and began MyLife software to better reflect the 
  114. efforts I was putting forth in the business. I had hopes and 
  115. dreams of being another Bill Gates. Well I must admit it 
  116. hasn't turned out that way, but I haven't given up either.
  117.  
  118. I started my business by writing small utility programs. My 
  119. first major application was a program that computed monetary 
  120. savings using various energy saving appliances and devices 
  121. as apposed to conventional products. It was a good program, 
  122. no sales, the company I wrote it for folded shortly there 
  123. after.
  124.  
  125. Several major projects later, I was faced with designing a 
  126. 30,000 line database application that would access 21,000 
  127. files spread over 12 drives in 600 subdirectories in a 
  128. network environment. Some application huh!
  129.  
  130. Well, in 1991 the thought finally occurred to me how do I 
  131. possible test, to the fullest extent possible the 
  132. applications I have written. Therefore I wrote BETARPT. The 
  133. use of BETARPT and an effective beta testing program reduced 
  134. the time I could deliver an application to a client, or 
  135. shareware market drastically.
  136.  
  137. The quicker I could turnaround a software application that 
  138. worked and was nearly bug free the more time I had to write 
  139. other applications. The idea worked and I'm inching closer 
  140. and closer to achieving financial independence. Look out, 
  141. Bill. 
  142.  
  143. The following pages are intended to provide you, the 
  144. software developer, the same flexibility I have gained. I 
  145. use something the big guys; IBM, MicroSoft, Borland and 
  146. others have been using all along, a beta test program.
  147.  
  148. I will assume that you are not new to the computer industry 
  149. and have some experience with computers and a general 
  150. business sense about you. In addition, I hope you are 
  151. generally knowledgable about computer bulletin boards, If 
  152. not you'll have to get smart before proceeding. 
  153.  
  154. The big guys have known all along that they cannot detect 
  155. all the possible bugs hidden within the applications they 
  156. have written. Even with a good beta test program bugs in
  157.  
  158.  
  159.  
  160.                             1
  161.  
  162. software do get released by major companies, some are; 
  163. MicroSoft-QuickBASIC v4.0, Central Point Software-PC Tools, 
  164. v7.0, Ashton Tate-dBase v4.0 just to name a few.
  165.  
  166. I won't focus on how to design your applications, market 
  167. them, or dream up new ideas for you. The sole focus is to 
  168. establish a method of allowing someone else, beta testers, 
  169. to detect potential bugs in your software. I have also 
  170. provided the basic tools for you to do this task. Two very 
  171. fine Shareware publications that will give you much useful 
  172. information on how to develop and market your Shareware 
  173. applications are;
  174.  
  175.      a. The $hareware Marketing $ystem
  176.         Seattle Scientific Photography
  177.         Attn.: Jim Hood
  178.         P.O. Box 1506
  179.         Mercer Island, WA  98040
  180.  
  181.         (206) 236-0470
  182.  
  183.      b. The Shareware Book
  184.         Compass/New England
  185.         Attn.: Bob Schenot
  186.         P.O.Box 117
  187.         Portsmouth, NH  03802-0117
  188.  
  189.         (603) 431-8030
  190.  
  191. These two applications would sure have made my life easier 
  192. as a Shareware author if I knew they were available when I 
  193. got started.
  194.  
  195. A final free plug. I would suggest a considering a 
  196. membership with the Association of Shareware Professionals. 
  197. This association is dedicated to the growth of the shareware 
  198. idea. The membership dues represent an investment, but; I 
  199. believe the benefits far outweigh the cost.
  200.  
  201.  
  202.                   WHAT'S IN THE PACKAGE?
  203.  
  204. The beta test package contains all the essential 
  205. information needed to develop a successful beta test program 
  206. within your organization. It is not designed to be totally 
  207. inclusive. The reason behind this is each shareware 
  208. developer operates differently. The scope of this 
  209. application allows you the flexibility of building on a 
  210. solid platform of proven performance.
  211.  
  212.  
  213.  
  214.  
  215.                             2
  216.  
  217. I really encourage you to read, evaluate, and see if such 
  218. an in-depth program will work for you. If you feel that your 
  219. business is destined to grow slightly, or take off like 
  220. wildfire and you use the ideas of this package then please 
  221. register this application.
  222.  
  223.  
  224. Manual
  225.  
  226. When we have received your registration fee we will 
  227. immediately send you the registered beta test packet. The 
  228. registered packet includes; a printed manual that is easy to 
  229. read. The manual has been designed exclusively for the 
  230. registered version.
  231.  
  232.  
  233. Ideas
  234.  
  235. Included are ideas for the development of a somewhat 
  236. aggressive beta test program. This program is the basic 
  237. platform for you to modify to your special needs. The 
  238. framework is there, and so is the ability to be successful.
  239.  
  240.  
  241. Files
  242.  
  243. See the file named 'PACKING.LST' for all files included in 
  244. the Beta Test Program application.
  245.  
  246. With registration you will be notified of product upgrades. 
  247. This is important because the ever changing software market 
  248. demands that you as a developer remain current to stay 
  249. competitive.
  250.  
  251. Included in the Beta Test Program is a file called 
  252. NONDIS.DOC. This file is a nondisclosure statement to be 
  253. signed by you and the prospective beta tester. It is 
  254. designed to protect you from a tester using your ideas and 
  255. immediately developing a similar application. The 
  256. nondisclosure statement is generic and should be reviewed by 
  257. an attorney in your state to compensate for individual state 
  258. laws.
  259.  
  260.  
  261.                        QUICK START
  262.  
  263. The quick start section provides a quick overview on how to 
  264. get the Beta Test Program up and running quickly. The quick 
  265. start is presented in a step by step process so follow 
  266. along.
  267.  
  268.  
  269.  
  270.  
  271.                             3
  272.  
  273.      a. Make a working copy of The Beta Test Program.
  274.  
  275.      b. Place the original disk in a safe place.
  276.  
  277.      c. Install The Beta Test Program on your harddrive.
  278.  
  279.      d. Use the command line option '\SETCOMPANY' to place 
  280.      your software businesses name in the BETARPT.EXE 
  281.      program.
  282.  
  283.      e. Use the command line option '\SETCOLOR' to make any 
  284.      color changes in the BETARPT.EXE program.
  285.  
  286.      f. Use the command line option '\SETDEVELOPER' to 
  287.      include any developer specific items you desire 
  288.      captured. Modify the BETARPT.HLP file to include a 
  289.      quick help screen for users. Developer help screens 
  290.      correspond to the help windows ^DEV1 thru ^DEV20.
  291.  
  292.      g. Modify the file README.DOC to include any changes 
  293.      to suit your tastes. At a minimum get the phone 
  294.      numbers and reporting procedures correct.
  295.  
  296.      h. Include the files; BETARPT.EXE, BETARPT.HLP, and 
  297.      README.DOC in a separate directory for beta tester 
  298.      use. These files must be given to the Beta Tester for 
  299.      knowledge on how to report bugs and use the 
  300.      BETARPT.EXE program.
  301.  
  302.      i. Establish some method of collecting bug reports 
  303.      from your beta testers.
  304.  
  305.      j. Establish some method of distributing your beta 
  306.      applications and the BETARPT.EXE program.
  307.  
  308.      k. Modify the appropriate changes to the files: 
  309.      APPLICAT.DOC and NONDIS.DOC.
  310.  
  311.      l. Widely distribute the file, APPLICAT.DOC, to 
  312.      solicit beta testers.
  313.  
  314.      m. Once beta testers are selected have them fill out 
  315.      and return the NONDIS.DOC to you. Make a copy of the 
  316.      form and mail a copy back to them.
  317.  
  318.      n. Distribute the beta application and the three beta 
  319.      test files mentioned in 'h' above.
  320.  
  321.      o. Complete and mail in the Beta Test Program 
  322.      registration form with appropriate payment. 
  323.  
  324.  
  325.  
  326.                             4
  327.  
  328. It's that simply! NOT... Seriously, the setup of a good 
  329. beta test program is time intensive. The above items clearly 
  330. are not as cut and dry as I have presented but they will 
  331. give you a good idea of what needs to be done.
  332.  
  333.  
  334.                WHAT'S A BETA TEST PROGRAM?
  335.  
  336. A beta test program is a program designed to remove 
  337. possible bugs from software prior to release to the public. 
  338. This also includes finding and correcting discrepancies in 
  339. the software's user manual or on-line documentation.
  340.  
  341. In short as a developer you go through at least 10 phases 
  342. in bringing your application from an idea to end product. 
  343. Those phases, or stages, are;
  344.  
  345.      a. Idea
  346.  
  347.      b. Flow chart
  348.  
  349.      c. Rough working model
  350.  
  351.      d. Refinement of rough model
  352.  
  353.      e. Draft working model
  354.  
  355.      f. Refinement of draft model
  356.  
  357.      g. Near final working model
  358.  
  359.      h. Refinement of near final model
  360.  
  361.      i. Marketing of software application
  362.  
  363.      j. Release of software application
  364.  
  365. You may not do all of them or not even in the order listed 
  366. above. I haven't flow charted since college! The point is a 
  367. serious application isn't developed over night.
  368.  
  369. The above phases are broken into four distinct groups, they 
  370. are;
  371.  
  372.      a. Design phase
  373.           1. Idea
  374.           2. Flow chart
  375.  
  376.      b. Alpha Test
  377.           1. Rough working model
  378.           2. Refinement of rough model
  379.  
  380.  
  381.  
  382.                             5
  383.  
  384.      c. Beta Test
  385.           1. Draft working model
  386.           2. Refinement of draft model
  387.           3. Near final working model
  388.           4. Refinement of near final model
  389.  
  390.      d. Marketing and Release
  391.           1. General marketing efforts.
  392.           2. Release of software application
  393.  
  394.  
  395. Design phase
  396.  
  397. The design phase is the period that you use too mentally or 
  398. on paper develop your application. It includes, but not 
  399. limited; user interface, file I/O structures, user base of 
  400. the software, and file design.
  401.  
  402.  
  403. Alpha testing
  404.  
  405. Alpha testing is designed to make sure that all features of 
  406. the product work with other hardware and software that you 
  407. have available. All alpha testing should be done in-house by 
  408. you or other individuals working directly on the 
  409. application. Alpha testing is always done before the product 
  410. goes to outside sources. In addition, all major bugs are 
  411. resolved. The software documentation and user manual is in a 
  412. draft stage. At this point the software should not have left 
  413. the development site.
  414.  
  415.  
  416. Beta testing
  417.  
  418. Once the in-house team has used the application 
  419. sufficiently to ensure the application doesn't routinely 
  420. lockup or blow off the software can be released for beta 
  421. testing. 
  422.  
  423. The beta test version of the software may be mailed to beta 
  424. testers or it may be made available to beta testers on a 
  425. local bulletin board.
  426.  
  427. In the beta test phase the application is put through the 
  428. paces of real world situations.  Beta testers help by using 
  429. the software in their day-to-day environments. The beta 
  430. testers provide more variety of testing to catch cosmetic 
  431. flaws, compatibility problems, and other peculiarities about 
  432. the software than in-house testing could possibly detect. 
  433. Beta testers use the software and report anything that is 
  434. not described by the manual, or seems to function 
  435. improperly.
  436.  
  437.  
  438.                             6
  439.  
  440. During this phase the beta tester is expected to report 
  441. problems to you, you attempt to duplicate the problem and 
  442. promptly correct the fault. Once several bugs have been 
  443. detected by testers and fixed by the programmer(s) a beta 
  444. test maintenance release should be issued to beta testers.
  445.  
  446. Once a maintenance release is issued the beta testers 
  447. should try to duplicate the errors they reported earlier to 
  448. see if they were corrected in the maintenance release.
  449.  
  450.  
  451. What beta testing is not
  452.  
  453. Beta testing should not be a phase for redesigning the 
  454. software. The primary purpose of beta testing is to find 
  455. problems the way the program currently stands. As with most 
  456. software, there may be features that the beta tester will 
  457. dislike. As a developer and marketer it is wise to listen to 
  458. potential customer comments, however; software redesign 
  459. should not occur. At this point the your software has gone 
  460. through some very timely processes and redesign would be to 
  461. time consuming.  Beta tester comments can always be added in 
  462. future software releases.
  463.  
  464.  
  465.            WHY IS A BETA TEST PROGRAM IMPORTANT
  466.  
  467. A beta testing program is important for two reasons; first 
  468. it allows the developer to detect bugs early and it provides 
  469. quicker turnaround of the application.
  470.  
  471.  
  472. Less bugs
  473.  
  474. The primary reason for a beta test program is that bugs are 
  475. detected before the software is released to the public. If 
  476. you have not sufficiently tested your software and released 
  477. your program potential customers will be finding the bugs 
  478. and move on to a competitors product without the bugs.
  479.  
  480. In starting my fledgling software business, MyLife 
  481. Software, I had a problem in effectively beta testing my 
  482. software. First I tried to beta test my applications. If 
  483. they were small I could do it just fine. Yet; larger 
  484. applications cannot be tested correctly by just one person. 
  485. I could not find all possible bugs that existed. Only 
  486. through a well managed program can software bugs be removed, 
  487. identified and fixed.
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.                             7
  495.  
  496. Quicker application turnaround
  497.  
  498. By using the beta tester to detect your bugs this provides 
  499. a greater opportunity for you to turn your applications 
  500. around quicker. As an example; consider 12 testers working 
  501. one hour a day on your application. This is 12 man hours. If 
  502. you had to test and debug your own software that is a day 
  503. and a half down the tube. 
  504.  
  505. After one week of using a dedicated group of beta testers 
  506. you will be able to detect more bugs than if you worked on 
  507. an application yourself for a whole month. If only one 
  508. individual debugs an application it defeats the purpose for 
  509. testing. One user only uses the application a certain way. 
  510. It would be very difficult for a single tester to alter 
  511. their style of use.
  512.  
  513.  
  514.           HOW WILL A BETA TEST PROGRAM HELP ME?
  515.  
  516. Most shareware developers write software in hopes of making 
  517. additional income. It is this driving force that should make 
  518. you want to have a good beta test program. The cost of 
  519. maintaining a beta test program is minimal in comparison to 
  520. potential revenue lost. 
  521.  
  522.  
  523. Less bugs
  524.  
  525. By making use of an effective beta test program you can 
  526. reduce the likelihood your target customer base will detect 
  527. any bugs. Nothing will cause the loss of sales quicker than 
  528. a nonfunctional or malfunctioning software application. I 
  529. speak from experience on this matter. 
  530.  
  531. More sets of eyes
  532.  
  533. Prior to release it is best to have as many eyes looking at 
  534. an application as possible. Those eyes can detect subtle 
  535. differences in user interfaces, help screens, or other 
  536. inconsistencies. I can't stress enough the importance of 
  537. this area. Even a non-computer user looking at the various 
  538. screens in an application may be able to provide very good 
  539. advise. You would be surprised that even a child can provide 
  540. useful input.
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.                             8
  551.  
  552.                 DEVELOPING A BETA PROGRAM
  553.  
  554. As in anything, developing a beta test program is more 
  555. difficult than maintaining it. Some thought is required for 
  556. development of a beta test program. Some large commercial 
  557. software companies offer 800 numbers that access a dedicated 
  558. beta test bulletin board and Federal Express all beta 
  559. releases. Others will use a message base on CompuServe. 
  560. Unless you are very wealthy I do not recommend this. An 
  561. effective program can be set up with a minimal investment of 
  562. money.
  563.  
  564.  
  565. Items needed
  566.  
  567. Several things are required to make reporting procedures 
  568. easier for your testers and distribution of beta test 
  569. releases easier for you. The absolute minimum items are; 
  570.  
  571.      a. A database program to maintain all valid beta 
  572.      testers.
  573.  
  574.      b. A bulletin board, or access to, to receive bug 
  575.      reports and distribute updated beta releases.
  576.  
  577.      c. On the bulletin board a message base is needed. In 
  578.      addition, a special user ID for each product tested is 
  579.      required to collect dedicated bug reports for review 
  580.      by you.
  581.  
  582. Ensure that when the bulletin board is set up that you have 
  583. a weekly bulletin that is available to beta testers that 
  584. provides them the status of the test. This is important 
  585. because it helps in maintaining the interest of the testers.
  586.  
  587. The above items are essential to get a beta test program 
  588. off the ground. The database is required to maintain 
  589. information about a potential tester likes and dislikes 
  590. about different software applications. It would make no 
  591. sense to send a beta tester a graphics application you have 
  592. developed if they do not use graphics applications. You will 
  593. find it is much more beneficial to select testers that have 
  594. an interest in the application you are asking them to test.
  595.  
  596. Your own bulletin board is a whole lot easier to maintain 
  597. bug reports and distribute beta releases than using one 
  598. belonging to someone else. However; if you cannot afford it 
  599. here's a recommendation. Select a bulletin board in your 
  600. area and ask the SYStems OPerator (Sysop) if you may use 
  601. their board to run your beta test program from. Most will be 
  602. more than willing to help. 
  603.  
  604.                             9
  605.  
  606. Soliciting Beta Testers
  607.  
  608. I would recommend several methods to gather a sufficient 
  609. number of beta testers. One method is to place a message on 
  610. several BBS's in your area requesting the need for beta 
  611. testers. Another place is Computer User's Groups. This group 
  612. may also be able to provide you with the name of additional 
  613. people who would really enjoy testing your application.
  614.  
  615.  
  616. What to give to testers
  617.  
  618. When you have accepted an individual to become a beta 
  619. tester the following files should be provided to the beta 
  620. tester from the Beta Test package;
  621.  
  622.      BETARPT.EXE  - Main report generator
  623.      BETARPT.HLP  - Beta report help
  624.      README.DOC   - Instructions for using BETARPT
  625.  
  626. These are the minimum files that should be provided. You 
  627. may decide to include additional files. This is your choice.
  628.  
  629.  
  630. Customizing
  631.  
  632. The BETARPT.HLP and README.DOC files are in ASCII format. 
  633. This was done intentionally to allow you, the developer, to 
  634. customize the format as desired. I encourage you to do so. 
  635. Altering the files will insert your companies favor and 
  636. attitude. 
  637.  
  638. A note on the help screens. Each help screen is delimited 
  639. by a ^ sign. If you look at the help file you will notice 
  640. the carrot(^). Do not remove the ^ or the capitalized 
  641. letters that follow it. Do not start a line with the ^ sign 
  642. as the BETARPT program will interpret this as a new help 
  643. topic. Each help screen is limited to 125 lines. I feel that 
  644. you should be able to say what is required within this 
  645. limit.
  646.  
  647. The README.DOC file will have to be minimally edited. If 
  648. you do not a FAX then you'll need to remove the references 
  649. to the FAX number. Also, you must insert your company name, 
  650. address, and phone number. If there are any special 
  651. procedures that you'll use on a regular basis this is the 
  652. file to put them in. Think this out and be sure you say it 
  653. clearly or you will get calls from your beta testers.
  654.  
  655.  
  656.  
  657.  
  658.                             10
  659.  
  660.                 MAKING A BETA PROGRAM WORK
  661.  
  662. It takes work to maintain and operate an effective beta 
  663. test program as I addressed earlier. If you are the chief 
  664. cook and bottlewasher of your operation then set aside time 
  665. solely to work with your beta test program.
  666.  
  667. I can't tell you what is an appropriate amount of time, but 
  668. the bigger the application the more time you should spent in 
  669. the maintenance of bug reports and answering beta tester 
  670. messages.
  671.  
  672.  
  673. Number of beta testers
  674.  
  675. This is a difficult topic to cover. The difficulty lies in 
  676. the selecting of beta testers. For some of you 10 to 15 good 
  677. beta tester should be sufficient. For others you might have 
  678. to select 40 or more testers to test effectively your 
  679. application. An absolute minimum of 10 beta testers should 
  680. be used to evaluate accurately your application.
  681.  
  682. I firmly believe more is better in the beta test arena. My 
  683. bias comes because no two users ever use an application the 
  684. same way. It only then seems logical more potential 
  685. application flaws can be captured by more testers. I should 
  686. add that this belief has not left me disappointed.
  687.  
  688.  
  689. Different pieces
  690.  
  691. When I have specific custom applications tested I tend to 
  692. break the major application into smaller pieces. An example 
  693. is if I were working on a large database application I might 
  694. send the report program to one set of testers and the screen 
  695. generator to another set and so on. I do this is done for 
  696. three reasons;
  697.  
  698.      a. Many times the application has a very specific 
  699.      business function. The time it would take to get a 
  700.      beta tester fully knowledgable about the application 
  701.      may exceed the test period. 
  702.  
  703.      b. The other big reason is I write a lot of 
  704.      proprietary software and I never allow a tester to 
  705.      have the whole application. It is not to say that I 
  706.      don't trust the select group of testers that help me, 
  707.      I just never want to test or tempt them.
  708.  
  709.      c. Many of my business applications are very large and 
  710.      would exceed the capacity of the average testers 
  711.      harddrive.
  712.  
  713.                             11
  714.  
  715. Spliting an application into pieces requires extra work 
  716. you. It may include you creating special script files to be 
  717. used. A script file is a dummy file that contains only the 
  718. essential information to run the selected application. In 
  719. the above example of the report generator you may develop a 
  720. test database to give to the tester.
  721.  
  722. The script files provided to the tester should be large 
  723. enough to cover every aspect of the portion they are asked 
  724. to test. If you fail to include an important section in your 
  725. script file that portion will obviously not be tested.
  726.  
  727.  
  728. Share the effort
  729.  
  730. Sometimes I like to share the effort. This means I ask a 
  731. group of testers to focus on a certain aspect of an 
  732. application. I personally dislike writing mouse interfaces. 
  733. In knowing my dislikes, I ask a group to check out every 
  734. screen in which a mouse appears or should appear. I may ask 
  735. any group to test only user interface and yet another to 
  736. test the help system. You could break your section into as 
  737. narrow or wide section as you desire.
  738.  
  739.  
  740.                 METHODS OF IMPLEMENTATION
  741.  
  742. Once you have got a BBS set up, a database on-line and are 
  743. ready to go here's the next step. I would recommend that you 
  744. ask local SYSOPs and users groups to pass around the files 
  745. APPLICAT.DOC and NONDIS.DOC. These files contain the 
  746. application that a prospective beta tester should fill out 
  747. and the nondisclosure statement.
  748.  
  749. Same testers
  750.  
  751. If a beta tester is helping you then by all means continue 
  752. to use this tester. After a while these beta testers will 
  753. become even quicker in submitting bug reports and prove to 
  754. be a valuable asset. Sometimes, in exploring the flip side, 
  755. you may have a tester with a very specific interest and can 
  756. exploit the testers interest on the one application during 
  757. each upgrade.
  758.  
  759.  
  760. Different testers
  761.  
  762. You should constantly be seeking new beta testers. It is 
  763. always better to have to many than not enough as I wrote 
  764. earlier. Bringing in new testers in the middle of a beta 
  765. test window should not occur. If you are a one person 
  766. operation you'll most likely be to busy dealing with your 
  767. present bunch of testers to bring new ones on board.
  768.  
  769.                             12
  770.  
  771. Only between beta test windows should you review beta test 
  772. applications and provide them access to the BBS or send them 
  773. an acceptance letter.
  774.  
  775.  
  776. Specific testers
  777.  
  778. Using the same testers repeatedly I have found not to be a 
  779. wise idea. You must constantly bring new blood into your 
  780. beta test program. The reason is beta testers learn your 
  781. style and idiosyncracies. I'm not saying flush out all 
  782. testers after every application test. Continually attempt to 
  783. acquire new testers all the time.
  784.  
  785.  
  786.             WHAT'S IN IT FOR THE BETA TESTER?
  787.  
  788. Generally a person gets involved in beta testing 
  789. applications because they have an interest in that 
  790. particular type of application. They get to use the software 
  791. before it is available to anyone else and can assist you in 
  792. making it the best possible. 
  793. Beta testers don't get paid for there services. They work 
  794. for the love of using new applications. If fact, some 
  795. testers even pay for the privilege of testing new software. 
  796. During the beta test phase of OS/2 v2.0 selected persons 
  797. paid $60.00 for the beta test disks and manuals. Hard to 
  798. believe, isn't it!
  799.  
  800. Beta testers play with your application several hours a 
  801. week and get to deal with the frustration of it not 
  802. performing as expected, writing you reports, and gaining the 
  803. satisfaction of their efforts being corrected in the final 
  804. release.
  805.  
  806. One benefit beta testers generally receive, is a registered 
  807. copy of the software they have tested so faithfully. This is 
  808. an important reward for their efforts. Sometimes it is not 
  809. possible to provide them a registered copy of certain 
  810. applications. As in the case of custom business software. 
  811. However; a beta tester may be able to become a client in 
  812. future software endeavors.
  813.  
  814. Sometimes you as the software developer may offer a 
  815. commercial software application as a prize to the beta 
  816. tester reporting the most valid bugs. You could also have a 
  817. random drawing for free software or hardware for any beta 
  818. tester who has submitted a valid bug during the beta testing 
  819. window.
  820.  
  821. If you maintain your own BBS you could set up special 
  822. message bases available only to valid beta testers. Another 
  823.  
  824.                             13
  825.  
  826. idea might be to raise there access time and file download 
  827. limit. If you run a registered pay board you should give 
  828. them free access.
  829.  
  830. As you can see, the privileges are few and the expectations 
  831. are high for beta testers. If you treat them well they will 
  832. work hard for you and be a cornerstone of your business 
  833. operation.
  834.  
  835.  
  836.                    WHAT IS BETARPT.EXE?
  837.  
  838. BETARPT.EXE is a beta report generator used for creating 
  839. bug reports. The program is designed to be used by your beta 
  840. testers. The reports are to be used by you the software 
  841. developer. This file, BETARPT.EXE, when used by the beta 
  842. tester will generate a bug report that will allow you to 
  843. isolate and fix a bug not detected during the alpha test 
  844. phase.
  845.  
  846. The BETARPT program is specifically tailored for developing 
  847. bug reports. Its only function is to do that, and it does it 
  848. well. Yes, I have debugged it!  I've used this program in 
  849. one form or another for over two years and it provides the 
  850. optimum information required for removing annoying bugs and 
  851. application flaws.
  852.  
  853. Before you complete any of the below operations it is 
  854. recommended that you create a working copy of The Beta Test 
  855. Program diskette. Use the DOS COPY command for this.
  856.  
  857. The disk you just created will become your distribution 
  858. diskette. Remember to distribute the modified diskette.
  859.  
  860.  
  861. Command line options
  862.  
  863. Command line options allow you to customize the BETARPT.EXE 
  864. program to fit your needs and color preferences. Three 
  865. command line options are offered.
  866.  
  867.      a. The Beta Test Program offers support to change 
  868.      colors suitable for your application. This is done by 
  869.      using the command line option \SETCOLOR.
  870.  
  871.           EXAMPLE :   C:\> BETARPT \SETCOLOR
  872.  
  873.           A menu will appear allowing you to select the 
  874.           specific items you desire to change. Changing a 
  875.           color is as simple as selecting the highlited 
  876.           letter. After all colors changes are made select 
  877.           the Quit option. You will then be prompted to 
  878.           save the new colors.
  879.  
  880.                             14
  881.  
  882.      b. In order to allow the BETARPT.EXE programs to be 
  883.      customized with your business name do the following;
  884.  
  885.           1. load BETARPT with the command line 
  886.           \SETCOMPANY.
  887.  
  888.           EXAMPLE A:\> BETARPT \SETCOMPANY
  889.  
  890.           2. At this point enter your company name and 
  891.      press ENTER.
  892.  
  893.           3. Next, place your street address and press 
  894.      ENTER.
  895.  
  896.           4. Enter your City, State, and Zip.
  897.  
  898.           5. Finally, enter your Technical support phone 
  899.      number and press ENTER.
  900.  
  901.           6. If the information is correct press 'Y'.
  902.  
  903.           7. If you desire to save the information you have 
  904.      just entered then press 'Y' and the data will be saved 
  905.      to BETARPT.EXE.
  906.  
  907. Your company information will replace the information 
  908. initially displayed on the main menu screen.
  909.  
  910.      c. Not all software authors require the same 
  911.      information and the Beta Test Program offers a method 
  912.      for the author to have an additional 20 items of 
  913.      information captured. In order to capture additional 
  914.      information start BETARPT.EXE with the command line 
  915.      '\SETDEVELOPER'. An example is provided below;
  916.  
  917.           EXAMPLE :    A:\>  BETARPT \SETDEVELOPER
  918.  
  919.      Once the program has loaded you are given a scrollable 
  920.      window with 20 selections. In the initial setup select 
  921.      any line by using the up and down arrow keys and 
  922.      pressing ENTER. After this is done you are asked if 
  923.      you desire to 'E'dit a line or 'Q'uit. Should you to 
  924.      edit a line the following applies.  The maximum field 
  925.      length is 40 characters for this particular 
  926.      instruction. Once you have entered the specific topic 
  927.      the beta tester will then be able to provide you with 
  928.      this requested information.
  929.  
  930.  
  931.  
  932.  
  933.  
  934.                             15
  935.  
  936.      Additionally, the BETARPT.HLP file should also be 
  937.      altered to provide the user with additional 
  938.      information about the specific item. The help topics 
  939.      are titled DEV1 - DEV20. The number refers to the 
  940.      specific item. A maximum of 125 lines by 58 columns 
  941.      may be used.
  942.  
  943.      Once all additional instructions have been entered in 
  944.      the above fashion select 'Q'uit instead of 'E'dit. You 
  945.      will be asked if you desire to SAVE the new 
  946.      information. Select either 'Y'es or 'N'o.
  947.  
  948.      The beta tester will then be able to use the 'F8' key 
  949.      to provide you with the additional information.
  950.  
  951.      d. The Beta Test Program offers support to change the 
  952.      hotkey when using the Beta Report Generator TSR 
  953.      option. This is done by using the command line option 
  954.      \SETHOTKEY.
  955.  
  956.           EXAMPLE :   C:\> BETARPT \SETHOTKEY
  957.  
  958.           A menu will appear allowing you to select the 
  959.           specific hotkey you desire to change. Press the 
  960.           function key letter that reflects the hotkey you 
  961.           desire to use. You will be asked if the selection 
  962.           is correct prior to saving.
  963.  
  964.  
  965. System Requirements
  966.  
  967. The BETARPT.EXE program requires the minimum;
  968.  
  969.      a. Monitor (Color recommended)
  970.  
  971.      b. Single disk drive
  972.  
  973.      c. 1 floppy disk
  974.  
  975.      d. DOS 3.0 or above
  976.  
  977.      e. 8086 processor or above
  978.  
  979. That is it! The entire program and the help file will fit 
  980. on a single 360k floppy disk.
  981.  
  982.  
  983.                    WHY USE BETARPT.EXE?
  984.  
  985. The need is clear for the use of this application. By 
  986. implementing BETARPT.EXE into your software testing and 
  987. development process you should be able to achieve new 
  988. heights in developing applications. This is no high 
  989.  
  990.                             16
  991.  
  992. pressure software sales pitch. By using BETARPT.EXE or even 
  993. you writing your own bug report generator, you could 
  994. literally save hundreds of hours debugging your own 
  995. software.
  996.  
  997.  
  998.               HOW WILL BETARPT.EXE HELP ME?
  999.  
  1000. The BETARPT.EXE application will directly help you by 
  1001. standardizing all bug reports submitted by beta testers. 
  1002. With this standardization in mind it will make your life of 
  1003. correcting software bugs much, much easier. I can tell you 
  1004. that having a printed report of a bug is a whole lot easier 
  1005. to read and understand than a scribbled note submitted by a 
  1006. friend. Not to mention the reports can be saved to a file 
  1007. for later recall in developing software updates because I 
  1008. have provided you with a product recommendation area.
  1009.  
  1010.  
  1011.                          SUMMARY
  1012.  
  1013. In summary I have attempted to provide the information and 
  1014. software used to create a successful beta test program. Once 
  1015. again, this information is by no means complete. With the 
  1016. thousands of software companies in existence today each will 
  1017. operate differently, and so will you. Use this information 
  1018. as the bedrock for the development of your own program and 
  1019. you will not be disappointed.
  1020.  
  1021.  
  1022.                         TRADEMARKS
  1023.  
  1024. I have used a few product names and software manufacturers 
  1025. and wish to give them credit were credit is due;
  1026.  
  1027. dBase IV is a trademark of Ashton-Tate, Borland 
  1028. International.
  1029.  
  1030. PC Tools is a trademark of Central Point Software.
  1031.  
  1032. QuickBASIC is a trademark of Microsoft Corporation.
  1033.  
  1034. IBM and OS/2 is a trademark of International Business 
  1035. Machines Corporation.
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.                             17
  1047.