前言
在Quality week上的一次演讲中,微软的一个测试经理,Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。这是一个非常可惜的情况,因为这样的bug report浪费了紧张的开发计划中的宝贵时间,增加了对产品质量完全是无关紧要的事情,同时导致了在开发人员和测试之间的挫败感和差的感觉。有时,bug report是由于短暂的或随机的事件,测试和开发之间不一致的工具和配置,或者在测试的环境下对正确的行为的模糊定义而产生的,但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰,被误解,或者只是文字的错误。
幸运的是,我学习到一些能够引起管理层注意,更清楚的和开发人员沟通并得到修复的编写优秀bug report的诀窍。这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报,而且在同开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这种方法编写bug report,8份bug report中大约只有一个没有被修复。
这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况,敏捷地监督已计划的测试的执行过程,这样你就可以拥有可靠的测试执行过程。
另外一个关键的因素-bug report,却没有得到太多的关注。这是非常令人遗憾的,因为优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下:如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误,他怎么能够修复问题呢?如果你不能够在bug report中提出象“保险杆标签”(bumper sticker)一样的错误总结来引起管理层的注意,你又如何让他们关心你们发现的问题呢?
Bug report的核心是对错误的描述。表格1中是一个关于好和差的错误描述的例子。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量:
以上10条技巧可以帮助你和你的小组提交准确简洁的,彻底校订的,精心构思的,高质量的技术文档。测试小组应该集中编写bug report的任务,测试组长和经理应该让测试组成员清楚地认识到编写优秀的bug report是一项首要的工作任务。衡量优秀的bug report的质量指标应该包括如下:
对管理层来说,是清晰明了的,特别是在概要这一级;
对于开发部门是有用的,主要是给出能够让开发人员高效地调试问题的相关信息
可以很快的将bug从“Opened”状态转变成“Closed”状态,减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。
改进bug报告的流程是需要花费一些时间的,但是也给予了效果显著的回报。首先,简单的流程改进了测试小组和高层、平行管理层之间的沟通,增强小组的信任度,名望和鼓励管理层给测试投资更多的资源。第二,平稳地递交报告给开发人员促进了测试和开发人员之间积极的关系。第三,更短的bug生命周期是更加有效的,在时间上之前花费在编写优秀bug report上的时间和后期由于返工差的bug report花费的时间相抵消。这些回报帮助开发流程通过有效的沟通和高效率的流程获得更好的产品质量。
|
|