Understanding the assignment

Aim

Obtaining insight into the (project) organisation, the objective and setup of the system development process, the system or package to be tested and the conditions with which it must comply, so that the other steps of planning can be controlled more adequately. 

Method of operation

The method consists of the following sub-activities:

1. Determining acceptants with acceptance criteria and other information providers (like quality assurance employees, domain experts, designers and system administrators) 
2. Studying the available documentation
3. Taking interviews.

In practice, this activity is executed in parallel with the assignment formulation; it is also somewhat underestimated. This mainly means that the test manager talks to too few acceptants, while it is especially vital early on to assess the expectations correctly and ‘issue feelers everywhere’ as test manager. This is necessary for the adequate execution of subsequent activities in the Planning phase, as well as to control the total test process correctly in the future. 

The following points of concern are especially important: 

• The number of acceptants and stakeholders for the total test process is much higher than for an individual test level and the moment is usually earlier on in the process, when expectations vary most. The test manager must obtain an adequate image of these expectations and the political situation. Where are the sensibilities? Where are the fields of tension? Is this project about time, money or quality? What is the underlying importance for the organisation? What is the position of the stakeholders in the project? What are their test goals? 
• The master test plan has relationships with various other plans in the development or maintenance process, as described earlier in the context of the master test plan. The test manager must inventory these relationships and elaborate them on the basis of the master test plan. 
• When it comes to documentation and interviews, the test manager must devote special attention to collecting the test basis, since this is not defined as a separate activity for the master test plan. 

Before starting the next activity – Analysing the Product Risks – the test manager provides feedback on the findings of this activity to the client for verification. 

Products

This activity provides the components below of the master test plan. The plan must specify clearly that these aspects concern a preliminary inventory and that it will be elaborated, updated and detailed at a later stage, in the separate test levels.  

• Acceptants and acceptance criteria 
  The acceptants relevant to testing and their acceptance criteria. 
• (Reference to) Test Basis 
  Generally speaking not all product requirements are listed in the (master) test plan. A reference to (the) document(s) containing the requirements must suffice. It is important to include a version number, so that the version(s) of document(s) on which the test is based is clear to all parties at all times. 
• Standards to be adhered to 
  The standards used are listed here. In terms of testing, one might think of instructions from the line organisation Testing, TMap, the TPI model [Koomen, 1999] or test manuals. Development standards, document standards or quality standards that are (must be) respected can also be listed here.  
• Documents related to the master test plan 
  This is a list of the documents that have a relationship with the master test plan. For instance a Project Plan or Plan of Approach for the project, specific project or test planning documents, a specific or generic test method, an implementation plan, or other documents of importance. 

Techniques

Checklist ‘Understanding the assignment’. See ‘Checklists‘.