在我的整个职业生涯中,我在QA方面取得了不同程度的成功.我承认我可以亲自接受错误报告,但通常当它们以自由形式制作时,其措辞更像是投诉:"这个过程仍然无效!",没有足够的信息来重现缺陷.
我愿意研究我对批评的敏感性,但我也对将质量保证流程去个性化并鼓励提供信息性错误报告的工具和技术感兴趣.目前,通过电子邮件或有时通过走路和语言表达错误来报告错误.
任何工具应该是:啤酒中的免费和易于安装/低管理.我也对博客文章,书籍或有关如何使自己对错误报告不敏感的文章持开放态度.
dre*_*ewh 10
获得真正的错误跟踪系统.FogBugz,Bugzilla,无论如何(我不是Spolsky的先例,但我会说FB是迄今为止我们测试人员最容易使用的系统,易于使用对他们来说真的很重要).这些更容易定义QA流程和错误报告工作流程.这应该有助于减少您和测试人员之间的个人互动.
不要亲自接受.我总是通过我们的错误跟踪系统和个人互动获得错误.无论他们的语气如何,我总是回答:"谢谢你抓住这个,我会调查它".他们可能有一个糟糕的一天,你可能有一个糟糕的一天,谁知道？如果他们没有提供足够的信息来重现,并且他们没有提供足够一致的信息,请参阅#1(获得真实的工作流程并坚持下去).
忘记工具.这是关于沟通. 您需要有纪律的人告诉您到底出了什么问题,他们是如何到达那里的,以及导致事件发生的任何特定条件.当人们写出"它已经破碎"之类的东西时,你还需要能够提供反馈.开发和质量保证管理需要谈谈双方需要什么.
关于敏感性,我发现态度胜过一切.每次看到错误报告时,都必须从"这不是个人攻击;这是解决问题和学习东西的机会"的态度开始. 一旦你设定了自己的心态,你的回答就会随之而来.
我会把工具推荐给其他人,因为我们使用的不是"啤酒中的免费".
您的首要任务是确保培养脱离流程的能力.这不是个人问题.话虽如此,尝试与QA(个人或通过CoC)进行沟通,在bug报告中进行编辑会适得其反("这个过程仍然无法正常工作!",正如您所写,没有帮助).该过程的目的是提高最终输出的质量.这种惊叹不会进一步实现这一目标.
作为一名基本上是开发人员的QA人员(自动回归测试),我想我已经能够看到这个问题的两个方面.
正如其他几个人所说,这是一个沟通问题,没有工具可以解决它. 诸如bugzilla之类的工具可以提高通信效率,但它们仍然需要双方努力保持通信线路的畅通.
我已经看到开发人员经常在个人接收错误方面遇到麻烦,这导致他们将其视为"不重要","边缘情况","按预期"等,当问题实际上是一个问题时.即使问题实际上并不重要,只需在修复错误时分享您对风险/回报的评估有助于促进更好的沟通.
相反,QA人经常忽略错误的细节和重现它的步骤(包括我自己).当您作为开发人员遇到缺失的细节时,您的工作就是向我们询问更多细节(并请您及时地问我们).最糟糕的感觉是当你写错误并将其发送给开发人员,然后几天没有回复任何消息时,它会被关闭为"无法重现".
最后,关键是双方的及时和善意的反馈.如果我(在QA中)正在与开发人员合作,当我向他发送错误并且似乎很乐意帮助解决问题时,他总是会回应,我更愿意花时间给他所有细节.
| 归档时间： |
|
| 查看次数： |
738 次 |
| 最近记录： |