• Unless you are dealing with "mission critical" software such as flight control systems, reactor control systems etc., your testing budget (time and money) will probably not be adequate to allow you to test everything as thoroughly as you would like.

• When you are deciding what tests to design for each function, consider the impact of a failure in that function. How much could it cost? How difficult would it be to recover from? Is there an available work around? How many people would it affect? How visible would it be to people outside your department? Your organization?

Consider the following example:

A complex suite of software designed to fully automate the daily operations of a public library consists of several modules, all of which must be able to access the library catalogue (list of books). These modules include:

• Cataloguing (maintaining the book database)

• Book Issue and Returns processing

Now consider what would happen if one of these modules had a fault which prevented access to the catalogue, and which would require two days to fix.

If the fault was in the issues/returns module, then the library would be unable to issue any books, or to update any information about books returned. The library would be virtually shut down for two days, hundreds or thousands of people would be affected, and the fault would be highly visible - almost certainly rating a mention in the local newspapers.

However, if the fault was in the cataloguing module, meaning that new books could not be added to the catalogue, what is the worst that could happen?

• The librarian would be annoyed

• Possibly one or two borrowers may ask for one of the new books that could not be added to the catalogue

But, the general operation of the library would continue almost unaffected.

Prioritize your testing by considering the impact a failure may have. If the impact is slight and you are short on resources, then move that group of tests down towards the bottom of your testing priorities. If you do run out of time and can't run all the tests you would like to, at least you have covered the more important items.

Once you have established your test priorities, you can then begin to think about what kind of tests you need to create. (You will obviously design many more tests for your high priority functions than for the low priority ones).

The easiest and most obvious tests to design are those that check the validation functions in your database maintenance and transaction entry functions. It's not a bad idea to design (and later run) these tests first. Design these tests so that all input is rejected, and your database is not updated.

Once you have completed the validation functions, then look to designing simple database maintenance and transaction entry tests that actually add records to your test database. When this has been completed, then begin your test design for the more complex test areas which are data and function sequence dependent. When you are planning these tests, concentrate initially on what each test must prove, rather than on the actual data to use in your test. Selecting the data can come later.

If you are familiar with the application, designing these tests won't be too hard. If you are not familiar with the application and have only a functional specification to use as a guide to the tests required, then your job will be harder. If you are in this situation, take some time to familiarize yourself with the application by talking to the people who are currently performing the work on a day by day basis. Although this should help you to design more appropriate tests, you need to be careful here on two counts:

1. If you have a functional specification make sure that the design of the new system will not change the way tasks are performed. Make sure also that you plan tests only for what the system is designed to do, rather than for what your user may expect it to do, if these two things are different.

2. Users may tend to focus on the unusual things that happen a few times a year, and often gloss over the important tasks which are done daily. Make sure you don't get misled.