我的QQ:18324258 朋友们,如果需要交流,请直接联系我的QQ,并说明相互学习,不要留给我QQ号,我不会动不动就上来看的。希望多交流,谢谢!

探讨一下测试的主动权

上一篇 / 下一篇  2009-08-31 12:06:42 / 个人分类:软件测试

探讨一下测试的主动权(和当时的讨论有关系,呵呵,特定环境)

 

呵呵,怎么感觉测试和开发是对立的关系呢?不是东风压倒西风,就是西风压倒东风。但我个人不这么认为,当然,如果BUG数成了考核的内容,那当然就不同了。

 

不过我还是建议,把部门、角色间人的关系按照项目管理来管吧。所有的人情事故都放在桌面上管理,就是沟通吧。

 

今天讨论的第一个问题:测试的轮数。测试要几轮才算是结束呢。无限。。。当然,也是不可能的,所以公司可能就规定是3轮,5轮,第一轮做什么?第二轮。。。。我觉得也没有问题,BUG是永远找不完的。公司规定的3轮可能是从公司的平均生产率上总结出来的。当投入产出比平衡时,测试就应该结束了。

 

做软件的也知道,计划永远赶不上变化,规定永远都会有特殊。这就是我们讨论的具体问题具体分析了。

首先,一般的情况下,不要把冒烟测试定义了一轮测试。也许你冒烟不通过,领导说测吧测试,测试总比不测试好。但实际上并不是这样,因为冒烟测试已经测试了产品的必须功能,这些是下面正式测试的基础。如果这些都不通过的话,后面可能大量的测试是无意义的。更不能采用其它特殊的方法勉强去完成测试,因为你临时调整的测试环境,换了旧的包之类的,都会导致这次测试并不真实,是可以尽早发现错误,但投入的测试资源和发现的BUG数远不成比例。 并且,你每次不可测试的版本都接收的话,那么,下一次、下下一次可能同样不合格的版本不停地提交过来。这样一来加大了测试人员的工作量;其次,测试人员发现BUG、记录BUG、开发修改还要通过BUG管理流程走一遍,其反工成本是大了几倍的。所以请把冒烟测试不通过的版本扔回去了。合格了再入来。

 

其次,每次的测试是应该根据计划来执行的,哪怕你的计划就是两行字。一旦计划有变更,象增加原来遗留BUG的返测。需要修改计划的。这里面有两个问题:1、你计划测试前,你应该考虑原来产品遗留的BUG是否需要返测。如果计划时没有考虑到这个风险,此时就比较被动了。 2、不得已的情况加入了,那计划一定要调整。不要把你有限的资源花在未计划的工作上,导致计划的工作不能完成。多做工作并不见得总是好事。完成目标才是第一位的。

 

第三,不要在测试过程中随意增加资源。原因:1、增加资源带来学习成本。2、增加资源在短期内是降低生产率的。即使你发现了更多的BUG。但发现BUG的成本远大于你投入的成本。假设你每测试人员每天发现10BUG你增加了两个测试人员,一天总共发现了18个,看视发现的BUG多了,实际上总的生产率是下降的。3.这也是计划的变更,增加了资源,就要增加下一轮的测试。不要就此结束,否则看起来,你原来的测试是有问题的,因为按照这样的理论下去,你增加108个人后,BUG就变成了780个了。4、可能你原来的测试真是有问题的,那么,继续吧。别停止。

 

第四,易用性的测试。易用性测试是开发关注最小,用户关注最多的。找两个方法吧:1、站在用户的角度上不停地向开发灌输易用性的重要。停止从开发的角度看BUG.  2、总结出易用性注意列表,提前给开发,让这些问题消灭到萌芽阶段。3、易用性注意列表不起作用怎么办? 那就是执行的方法问题了,不行的话用行政手段吧,呵呵。

第五,BUG的质量。可能100个问题出现1个质量有问题的BUG,可以不关注,但是写BUG的时候,要想想,开发是我们BUG的用户。站在他们的角度上考虑一下吧。BUG描述的不清楚,难以重现,属于重复。。。。。都会让我们的用户对我们有意见。当然要考虑BUG评审的投入产出比。但我们可以通过一些方式去改进。1、不停地强调BUG质量的重要性,测试人员在写BUG时就要特别注意。2、增加BUG审核,尤其到新的测试人员提交的BUG来说。3.增加客户满意度调查,哈哈,就是开发的反馈。

 

 

呵呵,写这么多吧。感觉和测试的轮数没有什么直接的关系。只是轮数如果限制了,各种各样的变化又发生了,结果导致测试很被动。

 

最后一句:如果你改变不了整个公司,就改变自己的部门吧;如果你改变不了自己的部门,就先改变一下自己吧。


TAG:

kandyhxc的个人空间 引用 删除 kandyhxc   /   2009-09-11 21:37:32
   喜欢最后一句话。
 

评分:0

我来说两句

Open Toolbar