- BUILD LOG.DOT
- BUILD REPORT.DOT
- END USER FEEDBACK LOG.DOT
- END USER FEEDBACK REPORT.DOT
- TEST FAILURE LOG.DOT
- TEST FAILURE REPORT.DOT
Notice that I have kept these templates generic-different businesses have different requirements and audit standards, so the templates can be modified as necessary. To install them on your machine, create a new directory called TMS under the Templates subdirectory in your Microsoft Office installation, and then copy the files to this location. Now start up Microsoft Word, and select the New command from the File menu. The templates should appear under the TMS tab of the New dialog box.
It's very easy to think of the debugging process as being synonymous with the testing process. Certainly, the distinction between the two processes blurs on small systems at the unit testing stage (to be defined a bit later).
Testing verifies that a software deliverable conforms precisely to the functional and design specifications that have been agreed to by the users. That's a formal definition. However, testing is also used in the detection of bugs-not to prove that there are none, but to locate any that are present. It is a sad fact that we all inadvertently code bugs into our applications. The trick is to reduce the number of bugs in a deliverable to as few as possible so that the system is completely operable. In an ideal world, we would continue to hone and refine the application ad nauseam until it was practically bug-free, but the users can't wait that long, unfortunately. As a general rule, bugs are found and eliminated exponentially-that is, it gets harder to track down bugs as time goes by, but that doesn't mean that they aren't there. When the product is released, they will pop up from time to time, but the user's perception will be-we hope-that the application is stable and robust.
The Formal Test Cycle
Before we get our teeth too deeply into the Visual Basic way of programming, I think it's worth reviewing the different levels of testing that apply to all software development projects regardless of the programming language or target platform.
The nature of testing is so varied in its requirements that it is difficult to give generalized definitions. What is appropriate for a small (one- or two-person) application is totally unsuitable for a large (twenty-person) development, whereas the amount of formality that accompanies a large project would slow down the delivery of a small application by a wholly unreasonable amount. With this in mind, I have tried where appropriate to illustrate the relative scale that is necessary at each stage.