This is the part of the sub-web covering the Implementation of Applications Software. To go to the overview of this sub-web, please click Overview. To go to the web-site home page, please click Home.

If a system has been purpose-written or specially modified for a customer it has a very high chance of containing errors or ‘bugs’ as they are commonly known. In this case it is sensible to test the programs. The approach to this is multiple:

• test individual programs to their individual specifications (unit test). This is, normally, carried out by the software developer, to ensure that there are no major errors. It would be useful if the test data could be retained so that subsequent modifications can be re-tested to ensure errors have not crept in;

• test to the specification (system test). This is, usually, undertaken by the developer but, in some cases, is undertaken by the customer. In this case try to generate test data for each of the conditions mentioned in the specification. This may produce weird combinations of data but it should ensure that these situations are tested. Before running the data through the system determine the expected result. This makes subsequent checking easier and less prone to errors. This test should ensure that all the customer’s requirements, as specified in the Statement of Requirements, have been met;

• test to live data (user test). In this test the data is taken from a typical week or month and then the ‘funnies’, which can occur from time to time, are added to ensure that all the likely occurrences of data are covered. Again expected results should be prepared.

• In some contracts there is mention of an acceptance test. This is usually the point at which the user accepts the system. To perform a satisfactory test to enable the user to accept the system, it is, probably, advisable to undertake both the system and user tests outlined above, and then follow this with a full parallel run.

If any errors are found then the evidence should be provided to the suppliers and, when they believe they have corrected it, the tests should be re-run. Take warning, however, as correcting errors in one area can cause new errors elsewhere.

It is advisable to keep the test data and test results so that the tests can be re-run on new versions of the software, to ensure that new errors have not occurred.