读书笔记：核心测试过程：计划准备和完善(三)

第三章

盯着水晶球：估算测试的工作量

3.1一个估算过程

估算的过程的checklist：

步骤序号

步骤内容

完成？

1.

与制定的测试组一对一或作为一个组整体工作，开发工作分解结构并估算进度

 

1.A

将测试项目分解成阶段

 

1.B

将每个阶段分解成组成的活动

 

1.C

将每个活动分解成任务和子任务，直到在组成的最低层的每个任务或子任务满足子任务特征

 

1.D

将风险优先级考虑在内，设置依赖关系，资源分配和在测试子项目内部的依赖性任务。文档的依赖关系，资源和在测试子项目外部的任务（指那些具有协作过程）

 

1.E

在子任务，任务，活动和阶段层次进行一致性检查。如果有可能，通过以前项目的数据以及工业界的标准等方面增强专业性的判断和获得直觉。如果有可能的话，找出解决测试子项目的进度表和项目进度表之间的不一致性。在不一致性无法解决时，在文档中记录遇到的困难。

 

1.F

向被分配负责每一项任务的人员核实工作分解结构和进度表，特别要注意找出任何隐藏的假定或依赖关系。

 

2.

使用工作分解结构和进度表来生成预算

 

2.A

从得到的工作分解结构中提取资源的完整性列表。对于每个资源，决定分派给项目的开始日期和结束日期。如果在一个给定的时间内，有些资源是在多个测试项目之间共享的话，了解在不同的时间周期之内分配给每个项目的每个资源占有的百分比。

 

2.B

找出支持这些资源所需的任何偶然性资源

 

2.C

将资源分类成人员，差旅费，工具，测试环境和存在的外包费用。按时间周期和分类得出总计。

 

2.D

对预算的明细表和总计进行合理性检查。如果可能的话，通过以前项目的数据以及工业标准等方面增强你的专业判断并获得直觉。

 

2.E

分期支付具有长期投资的项目，记录重用的机会，以及预计的支付费用时间周期。

 

2.F

如果是必须或想要这样做，分析投资的回报情况。如果投资回报是负的，在必要的情况下重复这个步骤，重新评价在步骤2.E中关于分期支付的假设。如果投资的回报依旧是负的，审查在估算的工作分解结构中哪些投资最多回报最少的项目，并追溯到质量风险。在文档中记录损失金钱的活动。

 

2.G

如果管理层允许，与测试组一起审查预算。尤其要注意找出所有遗漏的资源，特别是偶然性的资源。如果需要，重复步骤2.D-2.F.

 

3.

获得管理层对于估算的进度表和经费预算的支持。

 

3.A

展示测试子项目的优点。

 

3.B

概要列出为了得到这些特别的好处所需要承诺投入的时间和金钱。

 

3.C

了解并试图通过重复步骤3.A和3.B解决任何估算中的缺陷。

 

3.D

如果不能获得管理层对于提出的预算和进度表的支持和承诺，讨论将要删去测试的特别地方，设定为了获得管理层的支持必须达到的经费和/或进度表目标。

 

4.

如果必要就重复步骤1-3微调估算的进度表和经费，直到有足够的资源和管理层的支持承诺，使测试工作的（可能经过了调整）范围得到保障。

 

5.

将得到批准的经费预算和进度表的文档存放到项目的资料库或配置管理系统，将文档置于变更控制之下。

 

对于大多数的项目必须将这些内在的拖延和干扰考虑进去。

A Test Estimation Process

Step #

Step

Done?

       1.

Working one-on-one or as a group with the assigned test team, develop the work-breakdown-structure and estimated schedule.

¨

       1.A

Decompose the test project into phases.

¨

       1.B

Decompose each phase into constituent activities.

¨

       1.C

Decompose each activity into tasks and subtasks until each task or subtask at the lowest level of composition satisfies the criteria below.

¨

       1.D

Taking risk priority into account set up dependencies, resource assignments, and dependent tasks internal to the test subproject. Document dependencies, resources, and tasks external to the test subproject (i.e., those that involve collaborative processes).

¨

       1.E

Sanity check the durations and efforts at the subtask, task, activity, and phase levels. If possible, augment professional judgment and gut instinct with previous project data, industry metrics, and so forth. Identify and, if possible, resolve discrepancies between the test subproject schedule and the project schedule. Where discrepancies cannot be resolved, document the obstacles.

¨

       1.F

Review the work-breakdown-structure and schedule with the individuals to whom you’ve assigned responsibility for each task, taking special care to surface any hidden assumptions or dependencies.

¨

       1.G

Review the work-breakdown-structure and schedule with the entire test team along with any subject matter experts available within or outside your organization.

¨

       2.

Use the work-breakdown-structure and schedule to develop a budget.

¨

       2.A

Extract from your work-breakdown-structure a complete list of resources. For each resource, determine the first and last day of assignment to the project. If you have resources shared across multiple test projects within a given time period, understand the percentage allocation of each resource’s assignment to each project during various time periods.

¨

       2.B

Identify any incidental resources required to support these resources.

¨

       2.C

Categorize the resources into staff, travel, tools, test environments, and, if applicable, outsourcing costs. Total by time periods and categories.

¨

       2.D

Sanity check the budget details and totals. If possible, augment your professional judgment and gut instinct with previous project data, industry metrics, and so forth. Identify and, if possible, resolve discrepancies between the test subproject budget and the overall budget. Should resolution prove impossible, document the obstacles.

¨

       2.E

Amortize budget items that are long-term investments, documenting the reuse opportunities and the period of time over which you expect to recoup the costs.

¨

       2.F

If required or desirable, analyze return on investment. If the return on investment is negative, review your assumptions about amortization in 2.E and repeat this step if necessary. If the return on investment remains negative, review those items on your estimated work-breakdown-structure that consume the most money while contributing the least return, tracing back to the quality risks. Document the money losing activities.

¨

       2.G

If permitted by your management, review the budget with your test team. Take special care to identify any missing resources, especially incidental ones. Iterate steps 2.D through 2.F if necessary.

¨

       3.

Obtain management support for the estimated schedule and budget.

¨

       3.A

Present the benefits of the test subproject.

¨

       3.B

Outline the time and money commitment required to receive those specific benefits.

¨

       3.C

Understand and attempt to resolve any objections to the estimate through iteration of steps 3.A and 3.B.

¨

       3.D

If management commitment to the proposed budget and schedule cannot be gained, discuss specific areas of testing to be deleted, setting cost and/or schedule goals to be met to obtain management support.

¨

       4.

Repeat steps 1 through 3 if necessary, fine-tuning the estimated schedule and budget, until resources and management commitment adequate to the (possibly adjusted) scope of the test effort are secured.

¨

       5.

Check the approved budget and schedule documents into the project library or configuration management system. Place the document under change control

¨

Criteria of complete work-breakdown-structure decomposition for a test subproject

In a well-formed work-breakdown-structure for a testing subproject, every task at the lowest level of decomposition has the following characteristics:

1)      measurable status;

2)      clearly defined start and end criteria;

3)      one or more deliverables;

4)      an estimation of resource requirements, effort, duration, and other costs;

5)      a short duration;

6)      independence (once the start criteria are satisfied) from other tasks inside or outside the test subproject;

7)      clearly defined ownership, ideally one responsible person;

8)      maps to one or more of the recommended testing actions from the quality risk analysis (with all phases, activities, and tasks collectively covering all recommended testing actions); and,

9)      to the extent that dependencies and  resource constraints allow, activities and tasks occur in order of their risk priorities.