Testing

Any nontrivial program contains at least one bug. There are no trivial programs.

Seventh Law of Computer Programming

Historically, testing complex team-based applications has been broken down into two main areas: unit testing and system testing. In unit testing, the modules of the system are tested as individual units. Each unit has definite input and output parameters and (often) a definite single function. In system testing, the system is tested as a whole; that is, intercommunication among the individual units and functions of the complete system is tested.

Many of the problems experienced with testing Visual Basic applications occur because testers are trying to apply these conventional methods to systems for which they aren’t appropriate. There are fundamental differences in the ways that Visual Basic applications work compared with old-style applications. In Visual Basic applications, you can do things that have no equivalent in a non-GUI application—use a mouse and Visual Basic constructs such as check boxes, option buttons and command buttons, and menus, to name just a few. There are many ways of doing the same thing in a GUI application that would have only one equivalent way in a non-GUI application. An example of this can be found in Microsoft Word, in which you can save a document in at least four ways. To properly test this new type of application, you need to break the old testing methods into four test streams: destruction, window design, navigational, and functional.