lar compiler. A definition of fault report and change request procedures Compilers change as does the host hardware; high quality code together with the appropriate forms. will port easily to a different environment. 7. User documentation. For more complex systems, this may be Testing should be carried out in a controlled, repeatable split into a number of manuals, e.g. System Administration fashion. Test harnesses should be used whenever possible to Guide, User Guide and Overviews, User Reference Manual. exercise small, well defined parts of the code. All tests should A list of Fault Reports fixed. be set up to be repeated as necessary as they will form an 9. A list of Change Requests and work arounds. important part of the maintenance environments. Normally releases are given numbers of the form a.b where a is the major version number and is only changed when a new release 25.2.5 Integration contains significant enhancements, and b is the minor version num- ber which is increased for every release. When the individual code sections are completed, then the complete system must be built and tested. This is the point at which the use of a good version control system (and preferably full configuration 25.2.8 Acceptance testing management) is essential. Builds should be automated as much as possible, and one person must be given the responsibility of ensur- The user or customer, where feasible, should be encouraged to ing the system built contains the correct software at all times. provide a set of tests which he will run in order to accept, and sign Integration testing should concentrate on exercising the interfaces off, the software produced. These test will perform three functions: between individual pieces of code (as the internal functionality of the code elements should have been fully exercised during unit 1. They will ensure that there are no remaining misunderstandings testing). This level of testing is against the specification produced between the customer and the software team. Sets of repeatable tests s