Testing Your System

INFORMATION TECHNOLOGY

Testing Your System

One of the things you will always need to do is test your system.

You should test your system for two reasons:

• To ensure that it meets the system requirements
• To ensure that it operates correctly

For your coursework you are required to produce a test plan that would enable someone who knows nothing about your system to be able to test it thoroughly. This means that it must be sufficiently detailed, and not contain vague statements such as "Are all fields present?"

The easiest way to produce a test plan is to use tables, and possibly to break the plan down into sections. Depending on what your system does, you may have some or all of the following sections:

• Initial control states
• Dependent control states
• Validation
• Calculations
• Test Data

Here, the word "control" is taken to mean some feature on the screen, such as a field, menu option, or button that you have added. You do not need to test all of the menu options in Excel, for example.

Initial Control States

This section would contain a list of all the features, such as fields and buttons, that the system should contain. These could be taken directly from the system requirements.

In some systems, the order of controls may be important, so your test plan should take account of this. In some systems, the fields or cells may have default values, e.g. all values start at zero, or today's date, and your plan should also take account of this.

For example, the start of the test plan for the Peterson's address book might look like this:

• Surname
• Forename
• House number… etc.

• Surname
• Forename
• House number… etc.

Dependent Control States

This section of your test plan tests any part of your system that can change another part. For example, in a spreadsheet, changing one number could affect another.

If you created a "cash register" system, that looked up the price of an item and multiplied it by the number of items purchased to give a sub-total, the table might look like this:

Validation

This is the section in which you test your validation. Your table for the Peterson's address book might look something like this:

Remember that there are three types of data – you should check your validation for all of them:

• Normal - i.e. what you would normally expect the system to cope with
• Extreme - this is unusual data that the system should be able to cope with, for example the longest/shortest names and the biggest/smallest numbers.
• Exceptional - data that is outside the scope of the system (i.e. it should be rejected by the validation), which should ideally be dealt with gracefully, rather than causing the system to crash!

Calculations

If your system does some sort of calculations, it might be a good idea to test them in a separate section, where you can provide some example inputs and the expected results.

System Testing

You’ve now tested the individual parts of your system (sometimes called unit testing) – you also need to include some tests and test data to ensure that your system works as a whole. You should follow the flow of your system from start to finish, just as though your end user were using the system from start-up to close-down with real data.