It is my belief that software development is one of the most complex tasks that humans are called on to perform. And like many other human endeavors, developing software is not an exact science—even though it should be. Accountants, who arguably put as much mental effort into their work as developers do, at least have the benefit of being reasonably sure that the fruits of their labor are correct, because one set of figures balances with another. Software developers do not have precise debits and credits to verify the accuracy of their work, and so to trust that their software performs as intended, they must undertake the arduous process of testing each unit of code.
Although software development has formal guidelines that lay down techniques for drawing up logic tables, state tables, flow charts, and the like, the commercial pressures that are frequently placed on a development team often mean that a system must be ready by a certain date no matter what. Some people might argue with this observation, but it happens nevertheless. When a new computer system was implemented at the London Ambulance Service in October 1992, the number of system failures that occurred during its first few days quickly resulted in the staff abandoning it and reverting to a completely manual system. Different financial and managerial factors led up to this, but at the end of the day, the system failed because the testing process had not been conducted properly.
One of the biggest headaches for a software developer is time or, rather, the lack of it. When your project lead sits you down and asks you to estimate the amount of time that it will take to code up an application from a design specification that he or she has given you, it is difficult to know beforehand what problems will arise during the project. You are also faced with a bit of a dilemma between giving yourself enough time to code it and not wanting to look bad because you think that the project might take longer than the project lead thinks it will. The logical part of your mind cuts in and tells you not to worry because it all looks straightforward. However, as the development cycle proceeds and the usual crop of interruptions comes and goes, you find that you are running short of time. The pressure is on for you to produce visible deliverables, so the quality aspect tends to get overlooked in the race to hit the deadline. Code is written, executed once to check that it runs correctly, and you’re on to the next bit. Then, eventually, the development phase nears its end—you’re a bit late, but that’s because of (insert one of any number of reasons here)—and you have two weeks of testing to do before the users get it. The first week of the two-week test period is taken up with fixing a few obvious bugs and meeting with both the users and technical support over the implementation plan. At the beginning of the second week, you start to write your test plan, and you realize that there just isn’t time to do it justice.
I dread to think how many systems have been developed under these conditions. I’m not saying that all development projects are like this, and the problems are slightly different when there is a team of developers involved rather than an individual, but it’s an easy trap to fall into. The scenario I’ve described indicates several problems, most notably poor project management. Even more detrimental to the quality of the final deliverable, however, is the lack of coordinated testing. The reason I tie in testing with the project management function so strongly is that a developer who is behind schedule will often ditch the testing to get more code written. This is human nature, and discipline is required (preferably from the developer) to follow the project plan properly rather than give in to deadline urgency. The discipline I’m talking about is writing a proper test plan beforehand and then striving to write code that can be easily tested. The project management process should ensure that the creation of the test suite is also proceeding along with the actual development.
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 (defined a bit later). Other chapters in this book cover the debugging side of the software development process, which should allow the distinction to become more apparent.
In this chapter, I’ll start by covering the formalities—that is, the various phases of testing that a good development project will undergo. I’ll then outline a few tips that I think will help with the testing of a Visual Basic program, and I’ll finish up with a discussion of test environments. I’ve also included a few Microsoft Word 97 templates on the CD that accompanies this book. Although most companies will have their own in-house versions of these templates, I’ve included them as starting points for people who do not already use them. Each template should be self-explanatory as to its usage. Note that I have kept the templates generic—different businesses have different requirements and audit standards, so they can be modified as necessary. Just copy them to the Templates subdirectory in your Microsoft Office installation, start up Word, and select the New command from the File menu. The templates should appear under the General tab.