Project Quality Management Processes

Project Quality Management encompasses all of the work that is required to deliver the project’s product at the customer’s required level of quality. The PMI divides Project Quality Management into three major processes commonly shown as follows:

1. ■ Quality Planning: Planning the quality approach.

2. ■ Quality Assurance: Defining the level of compliance with requirements and incorporating continuous quality improvement into the test processes.

3. ■ Quality Control: Executing the testing and measuring results compared to the quality thresholds defined in the Quality Assurance processes.

These Project Quality Management processes are integrated into the phases of the Project Framework described in the previous section. This section describes the planning activities in the Quality Planning phase.

Quality Planning

An experienced test manager systematically plans the test strategy, selects the test execution methodologies, and specifies the testware if needed. Working with the project manager, the test project manager addresses the following planning objectives:

1. ■ Defining the strategy to accomplish the types of required testing.

2. ■ Implementing traceability between requirements and test cases to ensure good test coverage.

3. ■ Preparing the test cases and scripts.

4. ■ Reviewing all the test documents.

5. ■ Planning the data requirements and availability.

6. ■ Scheduling the execution.

When testing activities, cost, and schedule are planned without the benefit of the test manager’s input, the overall project schedule rarely includes a realistic timeline for the testing efforts.

Frequently, the test manager is not brought into a project until the project has already begun. Once a project is under way, the project manager is unable to make a retrospective test estimation effort and readjust the schedule. In this situation, the test manager must adapt to the predefined testing schedule.

Identifying the High-Level Project Activities

When the project scope is reasonably clear and documented, the project team identifies all of the major high-level activities that need to be accomplished to deliver the project. Members of the project team decompose the individual high-level activities into work. The decomposition of work is sufficient when the following requirements are met:

1. Can be completed in a short duration without further information inputs

2. Produces a deliverable (deliverables must have conclusions)

3. Can be estimated on the basis of realistic measurements

4. Cannot be broken down into further activities performed by one person

Estimating the Test Work Effort

Estimating the test work effort takes into consideration the types and costs of the resources that are required to complete the planned test. To estimate the cost of software testing, the test manager and project manager must consider the following:

1. ■ The number of testers and their rates

2. ■ The level of the testers’ experience and their productivity

3. ■ The cost of the hardware and software required to support the work effort

4. ■ The administrative overhead that the company assigns to project budgets

The test manager and project manager evaluate factors that influence the size of the test effort such as the following:

1. ■ The number of test cycles planned for the test execution phase

2. ■ The number of interfaces that require testing

3. ■ The number of test batch runs

4. ■ The complexity level of the test conditions and cases

5. ■ The defect fix turnaround time agreed upon in the strategy

6. ■ The availability of the required test data

7. ■ The defect management and resolution process

8. ■ The change management process

Test Planning

Although the percentage varies according to the project, on average, the test team spends 15 percent of its total work effort on the critical tasks of defining the test conditions and preparing the traceability matrix, test cases, test scripts, test data, and execution plans.

Normally, the test conditions are prepared first and mapped with the business requirement documents to ensure that the test coverage is complete. The test conditions become test cases by establishing the data values required to extensively test the conditions.

It is recommended practice to decompose the entire application into its modules and subapplications to identify the conditions, cases, and scripts that make up the core of the test plan.

The test conditions and test cases are refined and categorized as complex, medium, and simple conditions/cases. The number of test conditions/cases, and the time to prepare the scripts constitute the major part of the test-planning activity. Deciding on the appropriate level of condition/case complexity requires the technical and functional expertise of the entire project team.

The work effort to execute the scope of testing—the time required to prepare the test plan, publish the test strategy, and review the deliverables—adds to the test-planning effort.

The project manager and test manager should also factor the daily defect meeting, conference calls, and other meetings into the planning and execution stages of the projects.

The sample project plan shown in Figures 24.1 and 24.2 defines the typical tasks that are performed in a testing project.

Of the various activities in the project plan, planning and execution are the key activities that determine the cost of resources and schedules required for the testing projects. During these two crucial phases of testing, various key deliverables are estimated. This will ensure the test team will have a focused approach and the delivery of the deliverables will bring each task to a logical conclusion so that the project can advance to the next task in the plan. However, it is not always necessary that a particular task be completed before beginning the next task. The project manager should analyze the task dependencies. A task dependency is the relationship between two tasks in which one task depends on the start or finish of another task to begin or end. The task that depends on the other task is the successor, and the task it depends on is the predecessor.

The following text describes some typical test dependencies and why they are important to test management:

Finish-to-Start (FS): Task B cannot start until task A finishes. For example, if you have two tasks, “Test Script Writing” and “Test Execution,” “Test Execution” cannot start until “Test Script Writing” completes. This is the most common type of dependency.

Start-to-Start (SS): Task B cannot start until task A starts. For example, if we have two tasks “Test Script Writing” and “Run Plan Preparation,” “Run Plan Preparation” cannot begin until “Test Script Writing” starts.

Finish-to-Finish (FF): Task B cannot finish until task A finishes. For example, if you have two tasks, “Test Execution Complete” and “Test Closure Report,” “Test Closure Report” cannot finish until “Test Execution Complete” finishes.

Start-to-Finish (SF): Task B cannot finish until task A starts. This dependency type can be used for “just-in-time scheduling” up to a milestone or the project finish date to minimize the risk of a task finishing late, if its dependent task slips. This dependency type applies when a related task needs to finish before a milestone or project finish date. However, it does not matter exactly when, and one does not want a late finish to affect the just-in-time task. You can create an SF dependency between the task you want scheduled just in time (the predecessor) and its related task (the successor). Then, if you update the progress on the successor task, it will not affect the scheduled dates of the predecessor task.

Effort Estimation: Model Project

The following describes how to effectively use an estimation template.

The critical activities for effort estimation involving functional testing are defined in the model. The time for each of these activities is arrived on the basis of the parameters defined and the experiences from the project team. Table 24.1 shows the tasks with which the project manager, test lead, and test engineer are typically associated.

Test cases are classified as simple, medium, and complex on the basis of the time preparation and execution times for these scripts. The baseline times required by project management activities and other project-related activities are estimated and entered into Table 24.2.

Table 24.3 shows the total effort for test planning, test execution, and test closure activities separately for test engineers and test project managers. The total person-days are calculated for each of these effort parameters, and total person-months are calculated. Normally, 22 working days are taken for a month to arrive at a person-month. The table also shows that the total number of individuals required can be calculated from the person-months. If the test execution schedule is already defined in the overall milestone project plan, one can estimate the number of resources required to complete the project within the given time.

The project team should establish the baseline for how many test conditions, test cases, and test scripts can be prepared and executed by the individual tester per day. This is critical to this estimate and will differ from project to project. Similarly, review activities should be calculated as a percentage of the activity for each of those activities.

Quality Standards

Planning the quality management approach for every project includes establishing quality standards. The standards are based on the level of quality that the customer will accept. Many companies require a quality statement that defines the measurable goals for product and project quality. The measurements are audited for traceability back to the testing that produced the test metrics. The planning techniques and processes described in this section will help the test team meet the quality standards.