Establishing the assignment

Aim

A test process starts with formulating the assignment, so that the aim, tasks, responsibilities and authorisations of testing are clear to all stakeholders. 

Method of operation

Formulating the assignment is one of the vital parts in a test process. When establishing the assignment formulation in the master test plan, arrangements concerning the overall test process with the stakeholders (including the client) are made explicit. Expectations are mutually aligned. The assignment formulation in the master test plan constitutes the overall assignment for all underlying test levels. The assignment formulation of each test level must be in line with it. 

An assignment formulation for a master test plan consists of the following components:

  • Client
  • Supplier
  • Assignment
  • Scope
  • Preconditions and assumptions.

These components are explained in greater detail below:

Client

The party giving the assignment to create the master test plan and execute the tests. It is important for the test project to acknowledge the person issuing the assignment to execute the various tests. This can be the project manager, often employed by or appointed on behalf of the user organisation. 

Supplier

The party responsible for creating the master test plan and/or the execution of the test assignment. This person is generally called the test manager or overall test coordinator. 

Assignment

The test manager supports the client in the formulation of a concise assignment. It must describe the purpose of the test process and a clear delimitation of the assignment. The client is emphatically responsible for the assignment formulation. 

Example 1:

The assignment to the test process covers the testing of all software (package and custom-made) that project XYZ will deliver. The scope of this project is described in section x.x. The software must be tested to the extent that a solid personnel administration with adequately converted data can be taken into production. The test process is split up into the test levels described in section y.y and set up in such a way that any risks can be identified in a timely manner. The aim is to issue a well-founded advice in relation to commissioning based on the insight into the quality of the system to be delivered. 

Example 2:

The master test plan represents a supplement to the project plan XYZ. This plan is used for e.g. project delimitation, scope, planning, etc. The project's aim is to render workplace support to BDE compliant. In simple terms, this can be translated as: 

  • Making XYZ suitable for running under Windows/XP
  • Organising access to workplace support via BDE.

The master test plan describes the relationship between test levels system test (ST), users acceptance test (UAT), and production acceptance test (PAT). The test activities in these test levels must be aligned as optimally as possible. This means that unnecessary, duplicate and/or non-testing of specific objects is prevented. The test strategy was created in consultation with the XYZ project leader and line manager Test & Support. The relationship between the test levels is described in general terms in the master test plan. The responsible party creates a separate detail test plan for each test level. 

The overall test assignment is:

  • Report whether, and if yes, which, risks <organisation> incurs when taking XYZ release 2006 1.5 into production on the basis of the tests executed within the selected test strategy. 

Example 3:

Use the project 'Centralisation SYS-VS' as a pilot to evaluate the proposed new test approach for the components as defined in the scope. Remain within the framework of the PID (Project Initiation Document) until the integration and explicitly exclude the overall project (SYS release 3.0) for this plan. The project has already been determined planning-wise; the approach must be subject to this. Components in the plan can be applied if they add clear value to the direct, ongoing activities and agreement has been reached, such at the discretion of the project leader. 

Example 4:

In the first phase of Chain Automation, several quality management measures – including test and evaluation activities – are organised. These activities must be executed in time and with insight into the desired quality on the part of all stakeholders. 

The plan describes the arrangements between the partners in terms of the tests and evaluations that are executed and which parties are responsible. It is established what insights and reports will be delivered on the basis of which decisions can be made. 

In addition to the primary assignment, the master test plan sometimes also contains a secondary assignment, e.g. improving the test processes of the relevant test levels, see example 3 above. A point of concern is that the test manager must include any additional time and resources in the planning and estimated effort. 

Scope 

This must describe the boundaries of the scope of testing. This specifically involves the scope of the test activities to be executed. It must include the following aspects (if applicable): 

  • system(s) 
  • conversions
  • Administrative Organisation (AO) procedures
  • Interfaces with surrounding systems (is the interface tested up to the other system or including the other system or even including the entire chain?). 

Furthermore it is important to describe which aspects are outside the scope of testing. In addition to these aspects, you should also think of: 

  • system changes not included in the project (e.g. hardware changes in the mainframe platform) 
  • test activities that are executed by other parties
  • reorganisations
  • possible future projects with an impact on this project (in particular if other projects are not yet clear).

Tips

  • Add an image that shows a visual representation of the scope by drawing a line around the in-scope systems, interfaces, AO, etc. 
  • Do not exaggerate the list of aspects not included in the scope. This might seem highly defensive or even self-evident.
Preconditions

Preconditions are understood to mean conditions imposed on the test process by third parties, such as the client, the project or the users, within which the test process must operate. 

Assumptions

These are external conditions or events that must occur to ensure the test process' success, but that cannot be controlled by the test process. In other words, these are the requirements of the test process vis-à-vis others. 

Products

The assignment formulation as laid down in the master test plan.