如何确定QA问题是否为缺陷?

作为一名开发人员,我知道你总是会遇到让你在QA上发誓的错误——但我不认为应该把修复/不修复的决定交给开发人员——正如你提到的借口所证明的!!最谦虚的程序员对他/她的代码中出现的bug很反感,因此可能会给您带来麻烦。我认为测试人员和开发人员之间的一些摩擦是一个必要的恶果(如果你在一天结束时给他们买了一杯啤酒!)“这不是一个bug,这是一个特性”是一个常见的反驳,但有时是有效的,这可能就是为什么一个重要的人可能是来自业务方面的人(如果这对你的工作有意义的话)。

根据我的经验,记录东西是值得的,即使它们现在不可能修复——你总是可以分配一个滑动优先级等级,只需修复到某个级别。与测试人员/开发人员一起定期检查bug也会有所帮助。

我过去的做法是由一个人(产品经理)负责确定bug和新特性的优先级。PM根据以下标准决定每个项目是错误还是新功能:

• 如果软件做了一些与软件设计文档相反的事情,并且没有任何明显的优势,那就是一个bug。
• 如果软件做的事情不是客户(或其他人)想要的,但行为符合设计文档,那么它就是一个功能请求。

项目经理将与工程部以及客户代表讨论每个缺陷或功能请求,并在此基础上(以及常识和经验)为每个项目分配优先级。此外,将要求工程部为每个项目指明大致的时间表,项目经理将使用该时间表来计划下一次迭代。

简言之,bug是指软件没有按照设计人员的计划执行,而特性请求是指有人希望软件执行计划之外的操作。

SCRUM方法为这个问题提供了答案。产品负责人决定某个缺陷是否会在产品待办事项列表中创建项目。然后根据项目的优先级将其安排到迭代中。

功能性错误和UI错误很容易发现,争议也较少。设计缺陷是需要经过BA和开发团队才能获得意见的缺陷。此外,应单独跟踪与环境相关的问题,并且可能不属于缺陷类别。

有很多方法。其中一些:

1. 应完整描述软件需求。如果您看到一些需求没有得到满足,那么很明显,这就是bug。

2. 您可以看到,该要求已得到满足,但形式并不明显。它也是虫子。但在这种情况下,开发人员可能会说“一切正常”,并试图关闭bug。您可以通过以下方式找到您的意见(缺陷存在):

   • 示例如何在同一产品中实现类似的功能。
   • 示例类似的东西如何在类似的产品中工作(例如,gmail可以用作邮件托管的示例等等)。
   • 使用行业最佳实践。

3. 你看,有些东西是有效的,但可以改进。它也是缺陷:)。这与第2点类似,所有在这里提出的建议也适用于这种情况。