Testing Computer Software Second Edition

Common Software Errors - Source, Version, and ID Control

SOURCE, VERSION, AND ID CONTROL

If you're supposed to have Version 2.43 of the program, but some of the pieces you have are from 2.42 and others are advance bits of 2.44, you have a mess. You must know what you have, you must be able to tell from the code what you have, and what you have must be what you're supposed to have. If not, report a bug.

Some people calls these Bureaucracy Bugs because they reflect failures of labeling and procedure rather than operational failures. Only bureaucrats would worry about such things, right? Wrong. Or maybe right, but so what? They must be worried about otherwise the products shipped to customers will not be what you think.

OLD BUGS MYSTERIOUSLY REAPPEAR

Old problems can reappear simply because the programmer linked an old version of one subroutine with the latest version of the rest of the program. Many programs are split across dozens or hundreds of files: Programmers who don't purge old files frequently link old code with new by accident.

FAILURE TO UPDATE MULTIPLE COPIES OF DATA OR PROGRAM FILES

Some programmers repeat the same code in many different program modules. When they have to change this code, they may update 20 of the 25 copies of it, forgetting the others. As a result, they might fix the same error 20 times, but you might still find 5 more just like it the next time you test.

NO TITLE

The program should identify itself when it starts. You should know right away that you are now running Joe Blow's Super Spreadsheet, not Jane Doe's Deluxe Database.

NO VERSION ID

The program should display its version identification when it starts or when you give it a display version command. Customers should be able to find this ID easily, so they can tell it to you when they call to complain about the program. You should be able to find the ID easily so that you can tell it to the programmer when you find bugs.

If the program is made of many independently developed pieces, it pays to be able to identify the version of each piece. These IDs may not display automatically you may have to use a debugger or a special editor to find them. They are useful if they exist and if they are kept up to date by the programmers. However, unless you have firm management backing, do not insist that programmers compile separate version IDs for each module.

WRONG VERSION NUMBER ON THE TITLE SCREEN

Programs usually display a version number on the title screen or in an About dialog box. Usually, the programmer can change the code much faster than she can keep the correct version number updated on the title screen. The result is you might be using software version 2.1 but the title screen still shows 2.0.

NO COPYRIGHT MESSAGE OR A BAD ONE

The program should display a copyright message as soon as it starts. The message should include the copyright symbol (it is common to use (C)), the year(s) that the program was developed, copyrighted or shipped, your company's name and address, and the words All Rights Reserved. We use the following form:

If an earlier version of the program showed a copyright year of 1979, you should still say 1979 in this notice, along with this year's date. For more details, ask your company's attorney.

ARCHIVED SOURCE DOESN'T COMPILE INTO A MATCH FOR SHIPPING CODE

Before releasing a product to any customer, archive the source code. If the customer finds a bug, your company must be able to recompile this code and regenerate the product that the customer has. Without this starting point, you will have major problems addressing that customer's difficulties. This should be obvious, but it seems not to be. I've been amazed at how many companies can't recreate products they sell. They may have archival copies of source code, but the code in their vaults is a bit different from the code in the product they shipped. This is begging for a disaster. If you report that archives are not up to date with code that is about to be shipped, and are rebuffed, take it to a higher level. The president and the company lawyer might be much more concerned by this problem than mid-level engineering or marketing managers.

MANUFACTURED DISKS DON'T WORK OR CONTAIN WRONG CODE OR DATA

When the disks have been duplicated and the product is ready to ship, check a few disks. We are not suggesting that you take over the role of manufacturing QA. We are suggesting that any error that occurs in all manufactured copies of the product is an error you should find. Disk duplicators might crank out blank disks instead of the copies you expected them to make. It is embarrassing when you ship blanks as the product, and expensive to send customers replacement disks. This does happen. Over the last two years, I've received blank disks as a customer three times (three different companies). Similarly, the manufacturing group might duplicate the wrong version (Version 1.0 again instead of 2.0) or the wrong program (buy a database, get a spreadsheet instead), sometimes because you gave them the wrong disks to duplicate.