The ICT Lounge
Section 7.5:
Stage 3b - Testing a System
Once the system has been developed (created), it needs to be fully tested to make sure that it is functioning correctly.

Testing takes place during the second part of stage 3.

During the testing stage, every part of the system will be checked in order to locate any errors. These errors will be corrected and then re-tested to ensure that every part of the system does the job it was designed to do.
Key Concepts of this section:
Understand what is meant by systems testing.
Know the difference between unit testing and whole-system testing.
Be able to create a test plan, using normal, extreme, abnormal and live test data.

Stage 3b - Testing
Key Words:
Modules, Test Plan, Normal, Extreme, Abnormal, Live Data, Unit Test, Integrated Test
Testing individual modules (parts) of the system
When each module (part) of the system has been created it must be tested to make sure that it works correctly.

Examples of modules that should be tested include:
  • Data structures - do tables hold data correctly?
  • Validation rules - does the system reject unreasonable/incorrect data?
  • Input screens - does each form control allows users to enter data correctly?
  • Output screens - are output results correct, clear and complete?
Testing takes place as part of the third stage of the systems lifecycle.
System database modules need to be tested to make sure they hold data correctly.
System validation modules need to be tested to make sure that system errors are rejected.
System data entry modules need to be tested to make sure that data can be entered correctly.
System output modules need to be tested to make sure that results are correct.
System modules should be tested using a testing plan with normal, extreme and abnormal test data.
Any module errors found during testing need to be corrected and then retested.
Integrated systems testing is where the system is tested as a whole, across the entire organisation.
Fully tested systems are more likely to work properly and lead to a more productive workplace.

Testing individual parts (modules) of the system is known as unit testing.

Any errors found will be corrected by the person who created the module (a programmer for example).

The module that failed the first test will then be re-tested to make sure that the error has been fixed.

Using a test plan
Testing a system involves creating and using a test plan.

A test plan should be created for each system module should list all of the different tests that we are going to perform.

A good test plan should be created for every system module and include...
A list of the tests that are to be performed
The data to be used in the test
The type of test -(normal / extreme / abnormal / live)
The expected outcome of the test
The actual outcome of the test should be logged (Data accepted / rejected).

Testing with normal, extreme and abnormal data
A test plan should always use four types of testing data:
  • Normal data
  • Extreme data
  • Abnormal data
  • Live data
Imagine we were testing a system module (text box) to make sure that it will only accept entries of numbers between 1 and 5. The test data would look like the example in the table below:

The first three types of test data would be used to test the system BEFORE it was delivered to the customer.
Type of test data
Normal data
Data which should be accepted and pass the test without any problems.

(In our example, this was any number between 1 and 5)
The numbers 1, 2, 3, 4 or 5 should be accepted.
Extreme data
Data which is on the border of what the system will accept.
Using the same scenario as above, the numbers 1 and 5 would be used to test the borderline data.
Abnormal data
Data that should not be accepted by the system.

(In our example, this is any data other than 1, 2, 3, 4 or 5)
Examples of data that should be rejected by the system could be 0, 6, Two, Hello, etc.

Live data (below) is used to test the system AFTER it has been installed into the customer's workplace.
Type of test data
Live data
Data that is actually used in the customer's company.
Once installed into the customer's workplace,all modules would be tested with real-life data that the company actually uses.

An example test plan
The table below demonstrates an example test plan that could be used to test a system module that will be used to accept the age of a driving test candidate.

The cell should accept ages within the range of 17 - 70 . Any other data should be rejected:

Test number
Data entered
(test mark)
Type of test data
Expected outcome
Actual outcome
This section would be filled in by the tester and will log what actually happened as a result of each test.

If any of the actual outcomes were different to the expected outcome, the module would have to be corrected and then re-tested.
(error message)
(error message)
(error message)
(error message)

Testing the system as a whole
Once individual parts of the system have been tested and any problems solved, the system will be tested as a whole.

Testing the system as a whole is known as integration testing.

Testing the system as a whole makes sure that all of the individual modules work with each other correctly.

For example:
A data entry form might allow a user to enter their date of birth correctly but when submitted, this data might not be visible on the report.

Any problems found during whole system testing will be corrected and then re-tested.


Click the above task and answer all of the questions about the Testing Stage.

Please add your questions/comments below:

Links to Theory Units:
Section 4: Networks and the Effects of using them
Section 6: ICT Applications
Section 8: Safety and Security
Section 9: Audience
Section 10: Communication
Links to Practical Units:
Section 11: File Management
Section 12: Images
Section 13: layout
Section 14: Styles
Section 15: Proofing
Section 16: Graphs and Charts
Section 17: Document Production
Section 18: Data Manipulation
Section 19: Presentations
Section 20: Data Analysis
Section 21: Website Authoring