Documentation might be boring, but it's vital. The following (minimal) documentation set works well for Visual Basic applications:
Functional/Requirements Specification
The requirements should be written down, and this specification should reference a Visual Basic prototype rather than embed screen shots in the document. As a result, the document and the prototype together constitute the signed-off requirements. This combination provides a much more realistic representation of the requirements and leads to a solution that is much closer to what the users really want.
Design Specification
A concise design specification should be produced (and maintained). It should describe the key design points.
Excellently Commented Code
This form of documentation is key. In our experience, other forms of documentation invariably become out-of-date. How many times have you been asked to make a change to someone else's code? Do you trust the documentation, or do you review the comments and the code itself to find "the truth"? High-quality module and subroutine headers, excellent block and in-line comments, and good naming conventions are the best types of documentation possible. At TMS, we have tools that build "documentation" from the source files-it's a good test of the standard of commenting.
Test Plan
Testing within Visual Basic teams is generally too informal and ad hoc. Writing a test plan forces some advance thought and planning.
Testing
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.