怎么安排集成测试工作

敏捷是没有集成测试环节的，但大部门要求停下新功能开发，做两周的集成测试，所以，这个冲刺我们也没有安排开发任务。

以往集成测试怎么搞？

按照以往的经验，全员测试，从集成测试开始，每人每天必须提10个BUG，第二周5个，第三周3个。看到的效果就是，集成测试BUG多，很有成果，并且随着时间的推进，BUG在收敛！哈哈……人为收敛！

我的工作安排

我让部门内两位资深的测试分成两个组，全员参与集成测试，并让她们拿出测试计划、范围、分工、用例、规则等

到了晚上，结果出来了

计划：

采购转固单、实物卡片、财务卡片、变更单、清理单、调拨单、基础资料

——孙春艳 周艳 周健 司彦浓 清茂 李亚勇

计提折旧 月结 报表

——龙倩 骆佳 赵诣 勃然 志超

遗留任务：

赵诣参与的代码模型改造

勃然和清茂继续月结改造内容；

需求同学同时要兼顾规划概要工作；

测试同学保证用例完整性；

规则：

第五阶段遗留BUG在12月1日前清零，有困难的及时提出；

所有同学发现量至少为每天1个BUG，该要求只是提醒大家要主动测试；

16:00前提的BUG，个人遗留达到3个，考虑BUG分摊和加班处理；

项目经理每天16:30，按人头发出BUG发现量、BUG修复量

我看了以上分工，感觉很粗糙，范围是一坨，资源是一坨，这样的分工根本没有办法考核到人，要如何考核呢？

这时，我想到了以往的做法，即：BUG发现量。我终于理解为什么以往集成测试都是以BUG发现量为考核指标了！原因是，大锅饭不容易统一指标，所以就以BUG发现量为考核指标。

以BUG发现量为考核指标的坏处我觉得不用多说

- 只为了应付数量，而忽略了更有价值的BUG

- 以BUG发现量作为结果导向，而不是产品质量作为结果导向

不成熟的想法

这样安排工作比较简单，起初我也想这样做，并且提出两点改进

1.全员参与，开发人员也要提BUG

2.借助每日例会，根据大家手头任务情况，推算测试投入并确定每日计划发现量（投入低/中/高：开发1/2/3；需求1/3/5；测试3/5/8）

这样做就结合了敏捷，既不至于一刀切，不用只盯着数量，又能对结果有预期。

我自认为这个想法很棒！

改变想法

我把这个想法和项目经理沟通后，项目经理持反对意见，她认为这样做，只关注到人，而不是任务；并且她提出，敏捷关注团队，而不是个人——我清楚，这是敏捷的说法！我也知道，她说的是不对的！

我认为，上述概念错误的原因如下：

1.敏捷是没有集成测试冲刺周期的

2.KPI都是要明确到人的，该讲求团队速率的时候，就要讲求团队速率，该明确到人的时候，就不能吃大锅饭

现在是要说服一个人的时候了！

每当我要说服一个人时，我都会本能地先考虑一下我们共同的目标，那就是：集成测试要切实地提升产品质量。

对全员要求BUG发现量的做法，不论是一刀切也好，或是立会时动态计划也好，其实都是以数量为导向。以数量为导向，这就有违集成测试的初衷——以提升产品质量为导向

那么，我们应该怎么做呢？

目前我们的做法

我以前是做开发的，集成测试偶尔也会要求开发人员测试产品。如果这个功能是我做的还好，但大部分都是维护别人几年前做的产品。当时的我，既不懂业务，又不懂流程，我能测出来什么？于是，只能装模作样地点一点产品，其实我什么BUG也找不出来。

* 第一个结论就出来了：开发人员参与产品测试，能力很有限

作为开发人员，难道对产品质量一点促进的能力也没有吗？答案是绝对否定的！

* 第二个结论就出来了：开发人员参与集成测试是可以提升产品质量的

其实，开发人员是擅长一些测试的，哪些呢？比如，字段规则、字段间逻辑、数据反写等，需求文档中每一个点原本就是开发实现的，也是要开发自测的，这部分内容由开发保证质量，再合适不过了！

所以，要想让开发人员进行产品测试，就要：

1.给开发人员安排非常具体的任务

2.像对待测试新手一样，耐心地给开发进行指导

3.提供必要的文档及资料

经过以上思考，我提出如下方案：

1.开发人员负责功能测试或简单流程测试，业务负责测试用例及复杂流程测试

2.功能测试包括：字段逻辑、菜单操作、按钮操作

3.测试负责人重新制订计划表：按单据+功能为颗粒度拆分，明确到人

4.让开发人员交叉测试，即谁开发的单据，就让另一个人测，避免惯性思维

4.测试人员逐步完善测试用例：测试用例要与上述文档相对应，并按上述文档将测试用例明确到人

5.测试人员要对开发的用例进行抽检

目前做法的好处是

责任明确到每一个人，只关注结果

长远来看，测试人员逐步解放，不需要从流程到细节全关注

长远来看，开发人员在开发过程也会逐步养成自测的好习惯