Docstoc

Testing

Document Sample
Testing Powered By Docstoc
					                                                       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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:7/23/2011
language:English
pages:2