怎么安排集成测试工作
敏捷是没有集成测试环节的,但大部门要求停下新功能开发,做两周的集成测试,所以,这个冲刺我们也没有安排开发任务。
以往集成测试怎么搞?
按照以往的经验,全员测试,从集成测试开始,每人每天必须提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.测试人员要对开发的用例进行抽检
目前做法的好处是
责任明确到每一个人,只关注结果
长远来看,测试人员逐步解放,不需要从流程到细节全关注
长远来看,开发人员在开发过程也会逐步养成自测的好习惯