缺陷跟踪系统中隐藏的信息

上一篇 / 下一篇  2007-12-24 12:00:12 / 个人分类:国外技术文章翻译摘要

来自Dan Minkin
 Hidden Messages, SkickyMinds.com

翻译:iloveyouso

缺陷描述和开发人员的注释

测试人员五花八门的缺陷描述至少说明了几件事情。一是说明了哪些是有经验并且非常自信的测试人员,哪些不够自信。二是说明了哪些模块经常引起错误,以致在字面上很容易看出来,像“开发人员显然可以看到……”“这已经是第三次……”这样的话。这样也可以增加对于某些功能模块存在高风险的判断的把握。

同样的,开发人员的回复和之后的辩论也能反映出开发人员同测试人员的关系。从语言上能够看出来他们的关系不像所设想的那么好。回复的数量经常是3、4或者5个来回说明或者是缺陷解决的流程没能很好的工作,因此开发团队和测试团队需要改进交流、或者是关于需求还存在一些不明确的地方。

哪些字段被使用?说明测试人员是否把重点放在了正确的事情上?

在填写业务上的严重程度的时候比测试的优先级更准确说明了测试人员把重点放在了业务上而不是测试的影响,因此他们的重点对于他们应该扮演的角色来说有时会显得过于狭隘。另一个有趣的现象是在填写功能区域这个字段时,有的测试人员总是填写相同的内容而不是用这个字段来标识一个缺陷是在哪个功能中被发现的。和这些测试人员讨论之后发现他们不理解自己所测试的部分对应着整个的测试工作中的哪个部分。结果,我们用了一些时间对这些测试人员进行培训。

在我们询问为什么测试参照这个字段很少被使用的时候,我们发现了一个有用的信息:大部分的缺陷是在探索性的测试中被发现的,而不是遵循测试脚本。这一点从一个侧面揭示了外包商测试质量的问题。外包商使用我们提供的测试脚本测试他们的软件(以一种死板、不正确的方式),没有试图做一些操作让软件发生问题。这一点是这个项目一个非常关键的发现。作为改进,我们增加了两个中间阶段的测试,一个针对供应商的测试,另一个针对用户测试。

小结:

通过缺陷管理工具查找缺陷数据的时候,下面的几个问题会帮助你了解更多的信息:

  • 我是否已发现了缺陷描述中的主观的部分?工具是否如设想的那样成功的工作?如果没有,为什么?
  • 缺陷字段的选择和使用是否对测试流程是有正面意义的?
  • 谁对工具产生的数据感兴趣?
  • 有没有缺陷报告所没有包含的内容?
  • 缺陷的历史记录是否对于测试流程有作用?

TAG: 缺陷分析 国外技术文章翻译摘要

 

评分:0

我来说两句

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 5603
  • 日志数: 14
  • 建立时间: 2007-11-18
  • 更新时间: 2008-07-25

RSS订阅

Open Toolbar