Visual Basic —

Get the Users Involved

The intended users of a system invariably have opinions while the system is under development and, if given the opportunity to express these opinions, can provide valuable feedback. Once a logical set of requirements starts to become a real-life set of windows, dialog boxes, and charts that the user can manipulate, ideas often start to flow. This effect is the true benefit of prototyping an application because it facilitates early feedback. It is inevitable that further observations will be forthcoming that could benefit the overall usability or efficiency of the finished result. Unless you are working to very tight deadlines, this feedback should be encouraged throughout the first half of the development phase (as long as the recommendations that users make are not so fundamental that the design specification needs to be changed). A good way of providing this allowance for feedback is to make a machine available with the latest system build that is accessible to anybody. This will allow people to come along at any time and play. This is a very unstructured approach, but it can lead to a lot of useful feedback. Not only can design flaws be spotted as the system progresses, but other pairs of eyes become involved in the debugging cycle.

To make this informal approach work, it is necessary to provide a pile of blank user feedback forms that anybody can fill out and leave in some prearranged in-tray for the attention of the development team. A nominated individual should be responsible for maintaining a log of these feedback reports and should coordinate among the development team any actions that arise out of them. I've included a sample feedback form on the accompanying CD (see the list of Word templates at beginning of this chapter). Of course, a more elegant and up-to-date approach would be to use an intranet-based electronic form that captures all such feedback and bug reports.

Having extolled the virtues of allowing the users to give you continual feedback, I must point out one disadvantage with this approach. If the currently available build is particularly buggy or slow (or both), this could quite possibly cause some anxiety among the users and thus could earn the system a bit of bad publicity before it gets anywhere near to going live. Again, common sense is the order of the day. Some users are familiar with the development cycle and will take early-build system instabilities in their stride, but others won't. Make the most of the users and the knowledge that they can offer, but don't give them a reason to think that the final system will be a dog!

Track Defects

I mentioned earlier the importance of good project management, and now we are going to return to this concept. Depending on the size and structure of your project, the responsibility for keeping a record of the defects will either rest with a dedicated test lead or with the project lead (who is therefore also the test lead). Developers will find bugs in their own code, and in many cases will fix them there and then. However, some bugs will be too elusive to track down quickly, or there might not be time to fix them, so they should be raised with the test lead. Faults will also be raised by the users during their own testing, and also by anybody else involved in the test program. Unfortunately, it is quite possible that faults may continue to be found after the application has been released.

A suitable defect-tracking system will allow for the severity of defects to be graded to different levels (from show-stopper to irrelevant), and for each defect to be allocated to a specific member of the development team. Ideally it should also tie in with the local e-mail system. It is important to maintain an efficient means of tracking all defects so that the overall health of the project can be continually monitored. Toward the end of a development of any size there is normally considerable pressure from the business for it to be released. Before this can happen, however, the project lead and the user lead will need to continually review the defect status list until a point is reached when the user lead is satisfied with the correctness of the system. This can only be properly achieved by maintaining a thorough, central log of the current health of the system.