测试的价值不仅仅是找Bug

2010-05-04  张海江 

在测试工作中,一直以为测试的目标和价值就是在黑盒测试活动中找bug,以找到bug越多越自豪。但当我随着商业意识的不断积累,跳出测试的视角,站在公司的角度看测试时,会发现测试的目标是商业成功,而不仅是找bug。商业成功的关键是什么?简单点说就是可以长期地稳定获得大量的客户并获得足够的利润。而要想长期稳定的得到客户的喜爱,就必须提供让用户满意的质量,这是测试找bug的初衷。可是商业成功要解决的“大量的客户”,“足够的利润”,如何由测试来保障呢?
  “大量的用户”的获得有时关键就是看谁的产品先推向市场,先占领市场。因此一个词“TTM——Time to Market”就是非常重要的,测试应该支撑项目在满足质量目标的条件下能及时地推向市场,而不是拖延产品的发布进度。
  “足够的利润”就要确保成本越低越好。减少研发人力:减少开发人力和测试人力;减少研发时间:减少开发修改bug的时间和减少测试活动时间;就能帮助产品减少成本,提高产品的利润。
  项目成功的铁三角:质量,成本,进度。每一个关键因素都需要测试人员来做出贡献和支撑。如果仅仅只找bug,可能只支撑了质量,甚至有时也并未真正保障了客户想要的质量。那么测试如何支撑项目成功的成本和进度呢?这时需要的就不仅仅是自动化测试,虽然自动化测试能起到一定的效果。但更需要具有商业意识的测试领导者,站在公司的角度思考选择做正确的测试决策。
  下面就以一个案例来证明测试如何更大地发挥其应有的商业价值:
  如果一个项目有10个功能:3个功能支撑性能,3个功能支撑可靠性,2个功能支撑可用性,2个功能支撑基本功能。(客户最关心:可靠性,不太在意性能和可用性)
  测试如何支撑项目获得更短的研发周期和更低的研发成本:
  反面案例:
  一个测试思考简单化的测试经理,可能要求10个测试人员进行10个功能的全面测试。1个测试人员的生产力为:1个功能需要10天测试完成,1天发现1个bug。10个测试人员用了10天时间完成了测试,并在每个功能发现了10个bug,一共100个bug。
  1个开发人员的生产力为:1天修复1个bug。100个bug需要10个开发人员修改10天。
  总结:重点功能50个bug,开发人力:100人天。测试人力:100人天,项目用时:20天。
  正面案例:
  一个真正了解客户需求,理解公司商业利益的测试经理做了如下决策:用10个测试人员,2个人一组重点测试可靠性的3个功能和2个基本功能,用时5天,每个功能发现10个bug,重点功能共发现50个bug。其余5个非重点功能的测试工作量可以减少一半,用时2.5天,每个功能发现5个bug,非重点功能共发现25个bug。 开发人员10人,修改75个bug,用时7.5天。
  总结:重点功能50个bug,开发人力:75人天,测试人力:75人天,项目用时:15天。
  从以上数据可以看到,只需要测试经理或测试架构师多用一点时间来思考,以公司最终目标:“在保障满足客户需求质量的前提下成本更低,进度更快”为自己的工作目标。避免大而全的唯bug论,就可以发现在重点功能质量标准不下降的前提下,可以实现开发和测试都节省了25%的研发成本和25%的研发进度。
  测试如何支撑项目获得更高质量的同时有更短的研发周期和更低的研发成本:
  测试经理做了如下决策:用10个测试人员,2个人一组重点测试可靠性的3个功能和2个基本功能,每个功能发现15个bug,重点功能共发现75个bug,用时7.5天。其余5个功能的测试工作量可以减少为1/4,用时1.25天,每个功能发现2.5个bug,非重点功能共发现12.5个bug。 开发人员10人,修改87.5个bug,用时8.75天。
  总结:重点功能75个bug,开发人力:87.5人天,测试人力:87.5人天,项目用时:17.5天。
  从以上数据可以发现在同样的测试人力和开发人力情况下,最应该保障的重点功能发现了更多的bug,为原方案的150%,必须重点关注的地方的相对质量得到了提升,而研发成本下降为87.5%, 研发进度减少了2.5%。
  本文通过一个简单的案例故事,说明了测试的价值不仅是找bug,只要我们测试工作追求科学的思考,而不盲目的干活,那么我们测试执行活动也能在提高关键质量目标的同时,帮助公司降低研发成本,减少研发时间,全面真正支撑公司商业成功所必须的:更快的进度,更低的成本,更高的质量。
  希望我们广大测试人员能从平时的测试工具研究使用和测试脚本开发过程中多抬头思考,选择正确的事来做,做到事半功倍。要相信测试人员能创造更大的商业价值,而不仅仅是bug。
384°/3809 人阅读/4 条评论 发表评论

罗健  2010-05-06

这个说的挺好


熊志男  2010-05-06

测试的价值不仅是找bug,但是测试人员的本质工作需要首先做好,那就是找bug,然后随着对全局掌控能力提升,才可以考虑更多,从一开始就只顾胡思乱想,不去踏踏实实测试bug,那么何谈别的


张挺  2010-05-06

楼主花费大量的笔墨来说明了一个测试的优先级问题。

但是这个案例的分析却是根本站不住脚的。

1.你的案例上的人生产力根本就不相等。由此错误的依据得到的结论同样是错误的。
案例1,5人,10天,50个重点功能的bug;
案例2,2人,5天,50个重点功能的bug;
案例3,2人,7.5天,75个重点功能的bug;
这里很明显地可以看出,案例1的5个人和案例2的2个人的工作效率完全不等,案例2的人工作效率是案例1中的5倍!!!案例3的人和案例2的人工作效率相等,同样是案例1的5倍!!!

2.bug的发现并非是简单的线性关系。
并不是说投入更多的人力就能发现更多的bug。
案例2,2人,5天,50个重点功能的bug;
案例3,2人,7.5天,75个重点功能的bug;
这样的案例2和案例3的假设太不符合现实情况了。一般来说,你在开始的两天可以发现大部分的bug,测试5天之后,在软件质量达到一般水平的情况下,再追加的2.5天已经发现不了几个bug了,bug数量不可能保持线性增长。
也就是说,你在这里要面临一个投入更多的人力到重要功能上,却不能发现bug的风险。


我是很赞同对测试划分优先级的,但是事情并不是这么简单的,呵,测试是一个很讲机会成本的活动,在一项事情上花费时间过多,有时候不如把时间花到其他地方更有效果。


周文静  2010-05-11

测试的价值不仅仅是找Bug 确实是.


登录 后发表评论