程序员为什么不愿意修改BUG?

  无非是没时间,问题太小,重现不了,理解不了,在实际环境中不太可能发生,问题只出现在没有人用的非常特殊的设备配置上 ,改正缺陷的风险太大(特别是临近封版),不会影响程序的实际用户等。

  我们测试人员为什么苦恼?

  可能是觉得封版之前bug就应该全部解决(强迫症),也可能是觉得程序员没有理解bug的严重性,也许是bug明显违反规范,也可能是觉得缺陷肯定会影响到用户。

  我们为什么难以说服程序员去修改那些bug?

  说一说我看到的:测试员过于执着(bug并非必须修改),测试员不清楚说服程序员的技巧,测试员看轻自己(程序员一旦强势,测试员就低声下气),测试员技术水平低(不清楚修改bug的成本,可能只是加一个字段就能修复,开发说成本大,测试员就以为真的很大)。

  应对措施

  应对措施本应跟先将问题分类,分析根源之后再一一作答。不过本文不是严谨的学术报告,笔者只谈几点一般性的措施。

  如何说服开发改正bug?

  · 解释问题会怎样影响产品的正常使用?

  · 会破坏什么数据?

  · 用户如何经常遇到这个问题?

  · 市面上类似产品的有关评论

  · 指出类似的问题给客户带来的麻烦

  · 多引用技术支持收集的数据

  · 以前的版本通过了这个功能的测试

  · 与其他项目干系人沟通。找出如果程序错误不修改受影响最大的人(或修改后受益的人),确定程序错误会给他们带来多大麻烦。让关心这个模块的人去说服。

  · 列举一些场景,说明合理的用户在合理地使用程序时会遇到的程序错误,或产生的疑问。

  · 补充做一些后续测试,寻找该程序错误更严重的后果,或寻找比在错误报告中所描述的更广环境下出现的情况。

  

  注意点

  1、关于利用bug管理系统监视程序员的表现。有的测试经理尝试用bug跟踪数据来促使程序员修改bug,比如利用数据反馈某程序员是否存在大量的bug未修改,或是否修改时间过长,或是否总是推迟修改。是否应该推行这种制度笔者不做评论,不过笔者建议推行时需注意引导程序员的情绪,否则很容易引起某些程序员的反感,他们会在某些时候大肆放大测试员的无能,或者发表不利于测试部的言论。不过这也是正常的,bug管理工具只要被用于行政或人事管理,而不是技术管理,就会产生这些问题。

  2、关闭bug的权限应控制在测试员手中。除非经过测试员的验证,否则bug都不能闭环。在某些情况下,程序员会将未修复的bug置为“延期修改 ”、“非程序错误不予修改”“重复缺陷不予修改 ”,测试员需要且有义务对此提出质疑。

  3、尽量避免“延期修改”变为“永不修改”。在很多公司中,bug标记为“延期修改”即意味着“永不修改”。为避免这种情况,有一种可行的措施是在下一版本做项目范围评审时即提出这些缺陷,那时候的进度压力最小,而且项目经理也最理智、最清醒。另外,发现“延期修改”的bug后,若持反对意见,建议尽快跟测试经理或者项目经理进行沟通。

  4、bug修改后尽快验证,回归不通过后尽快跟程序员沟通,否则时间耽误越久,程序员记得的内容越少。

  5、如果bug多次回归不通过,或在临近封版时发现严重缺陷,不仅要在缺陷管理工具中记录,更应该直接找到相应的程序员进行沟通。

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注