System Selection - Platt & Hill Limited
Platt & Hill Limited, an independent company, specialising in the manufacture of products primarily for the furniture trade, commissioned us to select a replacement for their existing ERP system.More Info

IT Strategy & Systems Selection - Ferranti Technologies Limited
Ferranti Technologies Limited, a world-class supplier of electronic, electrical and electro-mechanical equipment, commissioned us to undertake an IT Strategy Study, followed by a Systems Selection.More Info

IT Strategy - a Stately Home
This 18th Century stately home is now run by a Trust. We were commissioned to produce an IT Strategy to enable evolution from a series of separate systems to an integrated suite of systems.More Info

Selection of Software Developer - Dyson Insulations Limited
Dyson Insulations Limited, which specialises in cavity wall and roof insulation, and home heating systems, commissioned us to select a software developer to develop new applications systems.More Info

Testing

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.