IT project testing

The Information Technology Services (ITS) testing framework provides best practice and structure around testing activities and processes for achieving a high level of quality assurance in the implementation of solutions. The purpose of the testing framework specification is to create a shared understanding of the overall targets, approach, tools and timing of test activities and service management function for the University's Enterprise Systems. We aim to achieve higher quality and shorter lead times with minimum overhead, frequent deliveries, close teamwork, short feedback loops and extensive collaboration.

In line with the University's strategic requirement to "...maintain and enhance the distinctive excellence of ANU" and ITS's strategic direction of "...transforming current IT business practice at ANU from one which is characterised by a legacy of disparate and organically developed architectures and processes, to a scaled, collaborative model that enables organisational efficiencies and consistent service delivery", this document aims to standardise and streamline the testing activities and processes making it transparent by providing guidance and visibility towards a standard practice.

Critical success factors

The following requirements are critical to the success of achieving effective and efficient testing outcomes and ensure that the end product meets the expected quality.

  • Testing considerations must begin in the early phases of an initiative/project.
  • Risk-based testing must commence early, identifying risks to system quality and using that knowledge of risk to guide test planning, preparation and execution.
  • Test case development must be based on key initiative/project outputs.
  • Testing must be objective and must be performed independent of the developers responsible for the application.
  • The defect management process must be functional as soon as testing begins, and must ensure that only valid and non-duplicated defects are processed.
  • Planning for the systems integration test should start early, as it will involve multiple initiatives/projects, systems, and business solutions groups/colleges.
  • The scope of regression test should be well defined and where possible, an automated tool should be used to perform regression testing.
  • Specification components/releases should be categorised by their relative importance to the business for defect prioritisation and performance testing.

Key testing requirements

Details and description of the following key testing requirements along with testing and defect lifecycle and processes are available in the document: Business Service Specification - Testing Framework.

  • Key stakeholder participation
  • Time management
  • Communication
  • Rules of engagement
  • Product induction
  • Quality assurance
  • User acceptance testing
  • Signoff
  • Roles and responsibilities

Working papers

Testing at times may require the use of various tools and techniques to generate/develop artefacts that support the development of testing documentation and the execution of tests. These are referred to as working papers and where it makes sense, these working papers should form part of the documents either added as an item in the document or attached as an appendix to the document.

From a testing perspective, Business Analysis (BA) artefacts are essential reference documents as they form the basis for the development and execution of test cases.

ITS testing is undertaken using the Hewlett Packard Quality Centre (HPQC) application.


Planning & development stage

* These documents are normally extracted from the testing tool that ITS uses for testing.


You may also need the Lessons Learnt Log outlined in IT project management.