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: Action Expected Result Pass/Fail Open the database The screen shows fields for: Surname Forename House number… etc. Click on the worksheet tab The screen shows columns for: Surname Forename House number… etc. …etc. … INFORMATION TECHNOLOGY 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: Action Expected Result Pass/Fail Enter 0 in Number of items The sub-total changes to 0 Enter 1 in Number of items The sub-total changes to be the same as the unit cost …etc. … Validation This is the section in which you test your validation. Your table for the Peterson's address book might look something like this: Action Expected Result Pass/Fail Enter 29/02/99 in date of birth field Date is rejected Enter 29/02/96 in date of birth field Date is accepted Enter "Friend" in Relationship field Value is accepted Enter "Business" in Relationship field Value is not accepted …etc. … 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.
Pages to are hidden for
"Testing"Please download to view full document