There are set procedures that should be followed to ensure that a system works. These procedures are grouped together to form a test plan. Testing is important and should:

• make sure the system meets the design specification
• make sure that the system returns the correct results and actually works
• give confidence to the end users: they will have more faith and confidence in a new system if it has successfully completed and passed all the tests.

It is important to understand the difference between an error and a fault. An error is a human action that produces an incorrect result. A fault is a manifestation of an error in the system - these are also known as bugs or defects. A fault may cause a software failure, it is a deviation of the software from what is expected.

Reliability is also a key factor in testing. Reliability is the probability that the software will not cause the failure of the system for a specified time under specified conditions. Testing is about ensuring the software is reliable.

Errors occur with software because people are not perfect. While they are working under constraints, such as deadlines, they can, due to the stress and pressure, make mistakes.

The amount of testing that is carried out on a system depends on the risks that are involved. A safety critical system, which would cause more risk if it failed, would need more rigorous testing than, for example, a stock database.

Testing is about trying to identify faults and rectifying them. The reliability and quality of a system increases as faults are identified and rectified.

When carrying out tests, it is important to consider other factors that may have an impact on the system. These may include contractual or legal requirements.

It is sometimes difficult to determine how much testing should be carried out. However, it is unlikely that all the faults will be found during the testing process. Large software vendors release patches to solve any bugs after the software has been released.

The test plan should ensure that the tests cover:

• the requirements
• pathways
• validation routines
• a comparison of the actual performance against the design specification.

• Test number: a unique identifier for each test.
• Description of test: an everyday language description of what is being tested.
• Type of test: normal, extreme, erroneous.
• Data used: the data that will be entered to run the test. It must be specified and if relevant, indicate where it will be entered. All data used must be given.
• Expected result: what you expect to happen when you run the test. For normal tests it should be a positive result. Incorrect data should result in an error message.

The format of the test plan is important because the test plan should be in sufficient detail to enable a third party to exactly recreate the tests and the actual results obtained. The test plan may also be included in the documentation that is passed over following the installation of the system.

The test plan aims to clearly document how each test will be carried out. The input data and expected output should be clearly defined. This will enable any discrepancies between the expected output and the actual output to be clearly identified. Any tests where there is a difference between the actual and expected results will need to be re-tested once the remedial action has been taken to rectify  the fault. These will need to be added to the test plan to ensure that it stays complete.

• Normal data: The data that is used everyday. It is data that is correct and should not generate any errors on entry.
• Extreme data: The data that is also correct, but is at the upper and lower boundaries of tolerance. It should not generate any errors when entered because it is normal data.
• Erroneous data: The data that is incorrect. It may be outside the boundaries of tolerance or be of the wrong data type.