6. Test Management

It frees up valuable development time

The tests are unbiased

Developers do not need to learn how to design tests

It reduces the need for communication between testers and developers

Over reliance on the independent test team

Developers get less opportunity to gain testing experience

Testers lose the chance to socialise with developers

Developers may lose a sense of responsibility for quality

Creating test specifications

Planning the tests

Prepare and acquire test data

Setting up the test environment

A Quality Manager

Any manager

Any tester

A Business Unit manager

Reviewing test policy

Monitoring test results and checking exit criteria

Introducing suitable metrics for progress monitoring

Reviewing tests written by others

Project planning done independently from test planning

Ensuring that each test level is tested separately

The use of specialists for specific test types (e.g. certification testers

The test management role is isolated from the project management role

Defining the test documentation

Assessing the meeting of exit criteria

Assigning resources for the different activities defined

Selecting metrics for monitoring progress

Defining the overall test approach

Preparing test specifications

Evaluating exit criteria and reporting

Reviewing actual results against expected results

Features not to be tested

Test specifications

Test conditions

Documentation standards for test procedures

The master test plan and test level plans equally

Test level plans only

The master test plan only

The test schedule

Known constraints

The number of failures encountered

The test schedule

The size of the development team

To know when a specific test has finished its execution

To ensure that the test case specification is complete

To identify when testers should stop working

To define when to stop testing

Test environment readiness

Estimates of expected testing duration being available

Test data available

Tool readiness in the test environment

Cost

Code coverage measures

The number of defects found

Estimates of defect density

Lines of source code

The number of testers available

Lack of coverage in certain areas and defects not fixed

Test environment availability

Estimates can be based on metrics of former or similar projects

Estimates can be based on estimates made by the owner of the tasks or by experts

Total testing effort depends on the outcome of testing

Estimating is pointless as estimates are never correct

Enable initial estimates of test effort to be made more accurately

Give visibility to the test activities

Evaluate tester ability for appraisal purposes

Determine metric requirements

Initial estimates of test effort

Holiday days taken by testers

Percentage of work done in test case preparation

Developer hours to date

BS 7925-2

IEEE 829

ISO 9000

BS 7925-1

The performance of the development team

The quality of the test documentation

The effectiveness of the testers

The outstanding risk

It collects metrics for monitoring purposes

It can set entry criterion requiring fixes to have been retested by a developer before accepting them into a build

Corrective actions taken may cover any test activity

Corrective actions taken may affect any other software life cycle activity

Tracking changes to testware

Version control of testware

Defining the format for test deliverables

Identifying items of testware

Project risks are used to prioritise tests and to determine the extent of testing; product risks are a development concern not a testing concern

Project risks are potential failure areas in the software or system; product risks are risks that surround the project’s capability to deliver its objectives

Project risks are the risks that surround the project’s capability to deliver its objectives; product risks are potential failure areas in the software or system

Product risks are typically related to supplier issues, organizational factors and technical issues; Project risks are concerned with poor software characteristics, potential to cause harm, and poor data integrity

Test priorities and the extent of testing

The need for and amount of test automation

The need for accurate incident reporting

The contents of the regression test pack

Suggestions on how to fix it

Identification of the test that failed

The developer who wrote the defective code

The cause of the incident

To provide ideas for test process improvement

To provide ideas for developer improvement

To provide ideas on how to fix the problem

To measure individual tester defect discovery rates