Test planning

Have your main holidays finished for another 12 months? Well if they have, before too long you will probably want to start thinking about next year.

But how did you decide where to go on holiday? You probably had a rough idea what you wanted then started looking in brochures. Maybe you discussed ideas with friends or colleagues. They may have given you some ideas based on their own experiences.

Once your chosen location was decided on, the next step was to plan when to go, how to finance it, the level of comfort you wanted, travel arrangements etc.

I'm sure you planned the holiday to make sure everything went as smoothly as possible with no room for error or problems. No doubt you learnt from your experiences and will apply that knowledge and experience to subsequent holidays you will have.

Relate this to testing, like a holiday, in any project there will be objectives defined as to what is required at the end. There will be a need to ensure the application meets the requirements.

In order to direct effort etc. in the right direction, an overall project plan is developed. Testing is of course a key element of any project so a solid test plan will also need to be produced at the right time (i.e. not just before testing starts).

This will need to detail how the testing will be undertaken from start to end with all the associated elements and interfaces. To the average project there are a couple of planning documents that can demonstrate and achieve proper test planning.

In any organisation to start with, there should be a high level Test Strategy or Policy that defines the process that should be followed in each project. This sets the standards for the processes, documents, activities etc. that should be followed for each project and just as important how the testing element integrates with the Project Management process.

Test planning needs to start as soon as the requirements for a project are known. One should also be pragmatic about the amount of documents that need to be drawn up. There need to be enough documents containing the right level of detail without going into 'documentation paralysis'.

The first document to be produced, once the requirements are known is the "Test Approach". The objective of this document is to set down at high level the approach for testing the application, and will cover all the main elements: e.g. what sort of resource is required, information on test environments and data, soft dates for the various activities.

There should also be information included about lessons learnt from previous projects.

Once completed, the "Testing Approach" needs to be signed off by all the relevant parties as agreement to the approach that will be taken. This sets down clearly to everyone at an early stage how the testing will be tackled, so there are no surprises later on when the Test Plan is issued for sign off.

Once the approach is understood and the project progressing, the detailed test plan can be written. Over the years we have seen many styles of test plans, with a variety of contents in the index. In many cases, test plans can be totally different for each project within the same organisation.

This should be focused by having adopted a test strategy that will address such anomalies. However, help is at hand. There is an international standard that we recommend should be adopted. This is known as lEEE 8291998. This is a comprehensive standard and gives a solid basis for future test plans.

The Test Plan is a key project document and will set down in detail all the necessary activities that will be undertaken.

When signed off it is a commitment that contents are understood, agreed with and any resource, environments etc will be provided as set down in the plan. The aim should be to have a standard template for everyone to follow and ensure all areas are considered.

The lEEE 829-1998 standard sets down the main headings to be covered as:

IEEE Software Test Documentation Std 829-1998

Test plan 

Purpose

To prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

Outline

A test plan shall have the following structure:

• Test plan identifier
• Introduction
• Test items
• Features to be tested
• Features not to be tested
• Approach
• Item pass/fail criteria
• Suspension criteria and resumption requirements
• Test deliverables
• Testing tasks
• Environmental needs
• Roles and Responsibilities
• Staffing and training needs
• Schedule
• Risks and contingencies
• Approvals

Going back to the holidays again. You don't just turn up somewhere and expect the holiday to happen. The concept applies to testing. Don't just expect it to happen and people know what to do. Make sure you are in control about what needs to happen where, when, how, why and by whom.

Clive Bates, OCS Consulting
info@ocs-consulting.com