Post by "ted", 09-18-2009, 16:12
-----------------------------------------------------
项目终于结束了，移山公司的员工和实习生工作质量如何？
阿亨说，还记得我当时立下的规矩--
绩效考核最重要的指标：发现的bug的数量
后来我的测试团队发生了一些很有趣的事，也导致了我的衡量标准一再发生变化。听我一一道来。
以bug数量为核心的政策出台后，我发现大家工作都很努力，但是有些人找到一些鸡毛蒜皮的小问题，也一个一个的单独发bug，另外一些人则是报一个bug，然后把一些相关问题都列在上面。还有就是别人已经报告了问题，但是相似的问题还是被不同的人报了上来。
所以我做了修改：
（1）一个问题只报告一次，后面重复报告的bug，不但不计入总数，还要倒扣分。
（2）同属于一个问题的子问题，不要报告多次。
这样就好了不少，但是有人提出来，"我花了两小时，经过仔细调研，发现了一个很严重的bug，但是别人两小时就报告了10个不痛不痒的bug。这样不公平吧！"
我想也对，于是就加了新的一条：
（3）bug的严重性也考虑在内。
过了两天，问题又来了，同学们反映：
a. 严重性的评判很主观。
b. 如果我负责的功能就不是太重要，那么即使有错误，也到不了"严重"这一级，这对我不公平。
c. 一些人把建议也当成bug，或者把还未实现的功能当成bug来报告，有些人整天琢磨一些异想天开的bug，但是规格说明书上写得很清楚，这些都不属于bug。
d. 好的开发人员的bug不多。 我要是摊上像白菜这样的开发人员，怎么办？我只有寄希望于和我合作的开发人员的低能，才能衬托出我的优秀，这好像太矛盾了。
怎么办？我还要改进，于是我又加了两条新的规则--
（4）严重性由阿亨最后定夺。
（5）如果bug被认定是"as designed"，那不算在总数内。
同学的最后一个问题d：[我只有寄希望于和我合作的开发人员的低能，才能衬托出我的优秀]，倒是问到了痛处，我还没有想清楚怎么办。没容我仔细想，最后事情发展到有点疯狂的地步。一天早上，一个测试人员跑来告诉我，他发现他负责的领域的bug已经被九条都报告了，后来才知道，原来我们每天晚上发布了构建后，九条就在深夜安装了最新的构建，然后先测试了别人负责的领域，把一些明显的bug都报告了。这样别人第二天再想创建bug，却发现bug都已"名花有主"了。
我后来问了阿超，他说，这听起来是一件好事呀。一方面你有很能干的测试人员，另一方面，也许另一个测试人员是多余的。
但是这样下去，所有测试人员都没有安全感，都要等构建一出来就玩了命地测试，而且还是从别人的领地开始测试。开发人员就可以讲"共同拥有源代码"，但是测试人员"共同拥有"什么呢？
另外，有些开发人员也反映，测试人员在平时讨论的时候交流并不积极，但是代码签入后，他们报告的bug非常多，如果能事先有沟通，就好了。但是测试人员好像就要等着你的bug，然后通过TFS来报告。
这些都让我反思原来的"数量至上"的衡量方法是否正确。经过和愚公多次E-mail交流。我得出了下面的改进方案--
我们还是要计算bug的数量，但是它只是一个次要的参考数据。测试人员要把重点放在如何让产品达到预期的质量标准，如何防止bug的发生，在每次我们发现一个bug的时候，我们都要问自己：
（1）为什么我们以前没有发现这个问题？
（2）产品中还有类似的问题么？
（3）有什么办法可以防止类似问题再度发生？
（4）我们能否自动检测这样的问题？
在bug数量的统计上，我们把重点放在每个发布（代码完成，Alpha，Beta）之后发现的bug才计算在内。在发布之前，Dev/PM/Test都应该为一个目标努力--让我们的功能在发布的版本中表现得最好。
[
b]Reply by "robert-nan", 09-19-2009, 12:17
-----------------------------------------------------
好文章。
一直觉得开发和测试不应该是对立的，而是应该有共同的目标就是把产品的质量做好。记得有本书上说，测试的工作不是要证明程序是错误的，而是要证明程序是正确的。
只有大家都向一个目标努力，才能成就一个积极的健康的团队。
Reply by "Arthas", 09-19-2009, 22:15
-----------------------------------------------------
用bug数来考核测试就如同用代码量来考核开发一样。
虽然知道这样不合适， 但是实在没有更好的办法。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图