Why counting is a bad idea

2014-09-12   出处: kojenchieh.pixnet.net  作/译者:kojenchieh

通常Test Manager会利用下面index, 来评量QA是否做的很好
No of Test cases prepared: 1230
No of Test cases Executed: 345
No of Test cases Failed : 50
No of Bugs reported: 59
No of Requirements Analyzed : 45
No of requirements updated :50
No of Transactions covered in Performance Testing : 24
No of Use cases Tested : 233

No of Test cases prepared Per Person Per hour = 5
No of Test cases executed per person per hour = 15

在这里你看到什么?

Manager 喜欢数字化, 任何东西都要量化, 这样比较容易管理, 不用再花去解释为什么你performance好或不好.

可是为什么用数字来衡量事件不好的事呢? 首先, 作者要我们先想想这些事情

Count Requirements
我们能count它吗? 要如何count它? 我们有条列的requirement 的list吗? 
我们有办法把requirement的内容用条列的方式表达出来吗? 那如何确保我们没有漏列? 那如何确保我们没有解释错误?

Count Test Cases
所谓Test cases就是你的test ideas. 描述你要怎样来进行测试. 所以它是一个概念性的, 并非完整的的东西. 通常要到测试运行时间, 整个东西才会清楚完整.

而且重点是ideas可以被count吗?

你会希望说你要产生多少idea出来吗? 我想你应该会出到好的idea难求, 你若是硬要凑数字, 下面的人也是会给你一些idea, 但, 那会是你要的吗??

Count Bugs
Bug最重要的是探讨它的严重性和对客户的价值. 每个bug代表的意义不同, 无法用相同的比重来看待每个bug. 所以重点不在于bug有几个, 而是有价值的到底有多少!!

所以重点不在数字, 而是在于背后的涵意. 你若是不能掌握的那个精神, 那数字就只是数字而已


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
234° /2341 人阅读/0 条评论 发表评论

登录 后发表评论