Testing

Many large organizations have departments devoted to testing. Others let their customers do it (that's what beta programs are for). In many cases, though, it's you, the developer, who often ends up testing products. This is a good thing. As a programmer you have to take responsibility for your code, and producing bug-free code is not only a matter of pride , but a time saver too. You'll be the one who has to fix the error, and you can guarantee that it will take longer to fix once you've forgotten what the procedure does. Putting the effort in at development time is nearly always quicker than waiting until the users find the errors.

Testing can take several forms, and if possible you should build time for these into your project plan.

Functional Testing

Functional testing can involve checking that the whole application, or just a part of it, does what it is supposed to do. The aim is to test every possible condition in the program. There are three ways to achieve this and they should be used in the correct order:

• Test it yourself, as you understand how it is supposed to work.

• Give it to the users; after all, they are the ones who know what it should do.

• Give it to a third party, along with the specification. If they know nothing about it, apart from what is written, they will not make any assumptions. They also will not worry about upsetting you if it does not come up to scratch.

When testing the functionality of the application, you not only have to test individual items, such as procedures, forms, queries, and so on, but also how they fit together. Just because a query runs, it doesn't mean that the code that uses it works - in the code you may use a field that isn't in the query. You need to test the individual items, and then how they work together.

Usability Testing

Usability testing really applies to the visible portions of the application. You need to know whether it is easy to use. Does it confuse the users? Does it follow the usual conventions? After all, if the users don't like the application, it doesn't matter how well it meets their requirements. You may have your own ideas about what is good but, at the end of the day, you must supply something that the user will be happy with. You may also wish to include the time it takes to accomplish a task as 'usability'. You may have to re-design your code if a particular function takes longer than acceptable to execute.

You should involve your users in the process of testing usability as soon as possible, preferably at the design stage - after all, what the application looks like and how it works are both part of the design. In some cases you can create dummy forms, just to show users what the application will look like.

Destructive Testing

This is a fun stage. Give it to someone and ask them to break it. Tell them to try the unconventional. Search for that unplanned problem. If you are testing a form, then let someone who does not use forms, or even computers, play around. If you are testing some code, then give it to another programmer. They will love the chance to break your code. You can be sure that once they have found a few glaring bugs to gloat over, you'll soon start to tighten up your own checking. It may hurt your pride initially, but in the long run you'll become a better programmer.

Maintenance

It is said that 60% of a programmer's time is spent maintaining old programs. When making changes to code, whether it is an old program or a new one, there are some important things to consider:

• Will the change you are making impact on anyone else? If it is a library routine then check with other people who are using your routine before making any changes. If there is an error in the code, other people might have coded around the error, so if you correct your code, theirs might stop working. You really want to avoid this situation if possible, and one way to achieve this is to create a new version of your library that is backwardly compatible without making a change to the interface. This way, current users of the system are not affected, and they have an option to update to the new version of the library.

• Keep focused on correcting the problem you are looking for. Don't get sidetracked if you find something else wrong.

• Only make one change at a time. Imagine correcting what you think are several problems, but when you run the code you get new errors. Which one of your changes caused this? If you track down problems one at a time, and test them one at a time, your overall maintenance time should be reduced.

• Comment your changes. Make sure that you add details of the change to the procedure header to show what you've done. You should also make sure that existing comments don't conflict with your changes - if they do, then change the comments to reflect the new functionality.

• Don't get distracted into 'tidying up' or improving code, unless that's the explicit reason you are modifying it. Remember that old axiom - if it isn't broke, don't fix it.

The above are really common sense, but you'd be surprised how often common sense flies out of the window when we have our heads stuck into code.

Important 

One product you may want to consider if you want stronger control over code maintenance either within a team or even if you are just working by yourself is Microsoft Visual SourceSafe. This product integrates neatly with Access and provides a way of tracking and commenting (in an external database) all the changes that have been made to Access objects and modules, and by whom. It then allows you to rollback to previous versions if required. There are many other features too, which are beyond the scope of this book. Visual SourceSafe can be bought separately or as part of the Office XP Developer edition.