您如何确定质量保证问题是否存在缺陷？

Question

我作为开发人员曾在多家公司工作过，最近又搬到了一家新公司的QA自动化公司。每个公司都不同，我还没有看到我真正喜欢的处理方式。质量保证常常会说某事是一个问题，而且反应要么“好，但要太难以修复需要太长时间”或“它不是一个错误，这是一个特征！”。 有没有人找到一种合理的方法来确定QA所说的某个bug是否需要修复？

Answer 1

作为一名开发人员，我知道你总是会在质量保证方面得到让你发誓（在你的呼吸下）的错误 - 但我不认为修复/不解决问题应该给予开发人员 - 正如所展示的那样借你提到的借口!!最谦虚的程序员憎恨他/她的代码中出现的错误，因此可能会给你带来困难。我认为测试者和开发者之间的一点摩擦是必要的恶魔（假设你在一天结束时给他们买啤酒！）。 “这不是一个错误它是一个特征”是一个常见的反驳，但有时是有效的，这可能是一个重要的参与者可能是来自业务方面的人（如果这对你所做的事情有意义的话）。

根据我的经验，即使现在无法修复，也值得录制内容 - 您可以随时指定滑动优先级，并将其固定到某个级别。定期检查测试人员/开发人员的错误也可以提供帮助。

Answer 2

我以前的做法是，一个人（产品经理）负责确定错误和新功能的优先级。 PM根据以下标准决定每个项目是错误还是新功能：

• 如果软件做的事情显然是错误的（即不是任何人想要或想要的东西）那么这就是一个错误。
• 如果软件与软件的设计文档相反，并且它没有任何明显的优势，那就是一个错误。
• 如果软件做的不是客户（或其他人）想要的东西，但行为符合设计文档，那么它就是一个功能请求。

PM将与工程师以及客户代表讨论每个错误或功能请求，并在此基础上（以及常识和经验）为每个项目分配优先级。此外，工程师将被要求指出每个项目的大致时间尺度，PM将使用它来计划下一次迭代。

简而言之，一个错误是当软件没有按照设计它的人那样做的时候，一个功能请求就是有人希望软件做一些没有计划的事情。

Answer 3

SCRUM方法提供了这个问题的答案。产品所有者决定是否存在在产品积压列表中创建项目的错误。然后根据项目的优先级将项目安排到迭代中。

Answer 4

功能错误和UI错误很容易找到，而且不那么有争议。设计bug是需要通过BA和开发团队获得意见的人。还应单独跟踪与环境相关的问题，并且可能不属于错误类别。

Answer 5

有很多方法。其中一些：

1. 应完整描述软件要求。如果您发现某些要求未得到满足，则显然是错误。

2. 您看到满足要求，但是以某种非显而易见的形式出现。这也是错误。但这种情况是开发人员可能会说“一切正常”并试图关闭该错误。您可以通过以下方式找到您的意见（存在缺陷）

   • 示例在同一产品中如何实现类似的事情。
   • 示例类似产品在类似产品中的作用（例如，gmail可用作邮件托管的示例等）。
   • 询问您的销售和客户关系经理人们对该功能的期望，从最终用户的角度来看它应该如何运作。
   • 使用行业最佳实践。

3. 你看到有些东西可以运作，但可以改进。它也是缺陷:)。它类似于第2点，所有推荐也适用于这种情况。

P.S。与其他部门的人讨论，讨论，讨论。