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.

Destruction Testing

In this type of testing, the application is tested until it does something it's not supposed to—often in a totally unstructured fashion. You need to come up with a happy medium of what is appropriate. For example, you had 20 days allocated for this testing, and you could let 1 person do this for 20 days or you could let 40 people do this for half a day each. Ideally, about 5 or 6 people for 3 or 4 days each is the best proportion to get the maximum benefit.

Window Design Testing

This kind of test proves that each individual window (such as primary, secondary, pop-up, dialog box, message box) that the system consists of has been designed and built according to the project standards. The best method of ensuring this is in the form of a checklist—that is, points to be checked and signed off by the test reviewer. An example of such a checklist is shown in Table 15-2, but each project should come up with its own checklist for its own project standards and circumstances.

Table 15-2 Example Window Design Checklist

Checkpoints Checked
The form positioning is correct relative to other forms on the screen.  
The form has the correct border style.  
The form has the Max, Min, and Control box set on or off as required.  
The control tabbing order is set and is logical to the user (upper left to lower right).  
Correct colors (foreground, background, fill, and so on) are applied to all controls per project standards.  
The first character of each word of text labels and menu choices is in uppercase text.  
Controls are aligned correctly.  
The text and captions of all controls are in the correct font and size.  
All menus, command buttons, check boxes, and option buttons have mnemonics set.  
All mnemonics are unique.  
Ellipses (…) are included for all routing menu choices.  
Shortcut keys for menu options are set if relevant.  
Command button and menu bar choices are unique.  
A Help menu option or Help command button exists if relevant.  
Command buttons are positioned appropriately on the form.  
A command button is set to be the Cancel default.  
A command button is set to be the Enter default if appropriate.  
Option buttons have a frame or group box.  
A default option button is set for each group.  
Combo box and list box entries are ordered appropriately.  
Enabled and/or Visible control properties are set where relevant.  
Date fields are formatted correctly.  
Image control is used rather than picture control where appropriate.  
3D and non-3D controls of the same type are not used on the same form.  

Navigational Testing

This test determines whether each window can be navigated to by initiation (via all the multiple ways of initiating) of all the different functions from any other appropriate window in the system, without necessarily performing any of the detailed processing that might be required when it gets there. Again, the best format for this test is a checklist, as shown in Table 15-3. Each list is unique to the particular window that is being tested. The list of navigational actions and results can be easily retested and verified by the test reviewer.

Table 15-3 Example Navigation Design Checklist

Navigation

Action Result Navigation Checked
File : New Entry fields reinitialized for new input  
File : Open Windows Open dialog box displayed  
File : Delete Customer details deleted after confirmation  
File : Print Windows Print dialog box displayed  
File : Exit Application terminated  
View : Customer Orders Customer Orders screen displayed  
Options : Toolbar Toolbar display toggled  
Help : Contents Application Help file contents displayed  
Help : Search Application Help file search displayed  
Help : Using Help Windows Help file displayed  
Help : About Application About box displayed  

Functional Testing

Having now tested that an individual window (or group of windows) is designed correctly, contains all the functions it should, contains the required methods for initiating those functions, and can navigate via those functions to all the places it has to go, you can now proceed to the "real" testing of the system. Functional testing ensures that the nuts and bolts functions of the system are actually tested. For example, when you initiate the Save function for a document (regardless of how you do it: via the mouse, the keyboard mnemonic keys, or a keyboard accelerator key), does the document get saved to disk correctly? The list of such tests will be a smaller list once the window design and navigational aspects of initiating a function are separated out. This part of the testing is probably the one that equates most closely (although perhaps not definitively) with the old concept of unit testing.

You would have one of each of these checklists per window in the application. Remember also that automated testing tools can be very useful for testing Visual Basic applications.

You should investigate many other forms of testing, among them these:

  • Regression test at check-in

  • Automated testing

  • Usability testing

  • Lots of pure pounding

Also, remember that bug tracking and the collection of metrics are both very important. A properly thought-out test strategy is vital for any Visual Basic 6 enterprise development. Shorten this phase at your peril!



Ltd Mandelbrot Set International Advanced Microsoft Visual Basics 6. 0
Advanced Microsoft Visual Basic (Mps)
ISBN: 1572318937
EAN: 2147483647
Year: 1997
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net