Image: Thumbnail of Report Cover

Download PDFPDF version of guide [3.0MB]

Download PDFPDF of Quick reference card [0.3MB]

Download PDFTips for PDF and HTML versions [0.5MB]

Download PDFWord version of checklists [0.1MB]

G – Types of testing

It is useful for executives involved with the development phase (such as the sponsor and members of the project board) to be familiar with the various types of testing, so they can make an informed judgement on the extent and results of testing proposed during development work. Testing of some sort is applicable to most project products, including for example, publications, computer systems, legislation or new call centres. The extent of testing significantly affects the quality and reliability of the product. Testing is discussed at page 94.

Types of tests, which can overlap, include:

  • component level or unit testing – of some small element of the project, such as a single ICT transaction or screen, or a single piece of equipment, or section of legislation;
  • module testing – of a group of components working together;
  • system testing – for all the components working together to achieve the desired effect or outcomes;
  • logical or function testing – that ICT or legislative components provide the results that are intended for each relevant set of circumstances;
  • volume or stress testing – that the products will handle the volume of work intended;
  • user experience testing – what the experience of using the product is like for clients and users, encompassing the full range of project products;
  • end-to-end testing – following the full path of possible usage of the project products. For example, from the application by a person for a payment, through to receipt of that payment by them. It is sensible to conduct end-to-end testing early – possibly with a limited set of functions – to help uncover any potential difficulties;
  • configuration testing – many commercial products require configuration to the particular needs of an agency. The basic configuration (for example, to an agency’s ICT infrastructure), and possibly different configurations for different business units, need to be fully tested;
  • usage scenario testing – where the application of the project products to a set of business scenarios is tested. For example, a scenario where an application for a payment is refused with a subsequent appeal and complaint could help test, among other things, an application form, staff training, and the drafting of legislation and regulations;
  • security, audit and recordkeeping testing – to provide specific assurance that these aspects of the requirements are properly met; and
  • pilot testing – using the project products in a real-world situation but with a limited number of users, to help discover any issues prior to full-scale implementation.