【发布时间】：2008-09-25 19:50:51
【问题描述】：
我曾在多家公司担任开发人员，最近在一家新公司进入了 QA 自动化领域。每家公司都不一样，我还没有看到我真正喜欢的处理方式。 QA 经常会说某事是个问题，而回答要么是“好吧，但它太难了，修复时间太长”或“这不是错误，而是一个功能！”。
有没有人找到合理的方法来确定 QA 所说的错误是否需要修复？
【问题讨论】：
【发布时间】：2008-09-25 19:50:51
【问题描述】：
作为一名开发人员，我知道您总是会遇到让您在 QA 处发誓（低声下气）的错误 - 但我认为不应该将修复/不修复决定交给开发人员 - 正如所展示的那样被你提到的借口！！最谦虚的程序员讨厌出现在他/她的代码中的错误，因此可能会想给你带来困难。我认为测试人员和开发人员之间的小摩擦是必要的（前提是你在一天结束时给他们买啤酒！）。 “这不是一个错误，它是一个特性”是一个常见的反驳，但有时是有效的，这可能就是为什么要涉及的重要人物可能是来自业务方面的人（如果这对你的工作有意义的话）。
根据我的经验，即使现在无法修复，也值得记录 - 您始终可以分配一个滑动优先级，然后将其修复到某个级别。与测试人员/开发人员一起定期审查错误也会有所帮助。
【讨论】：
-
詹妮弗是对的，总应该有一个角色让他有能力做出并负责拖延这种决定。不是测试人员，不是开发人员。可以是分析师，团队负责人..可能性很小。充其量是不依赖代码或测试的人，可以与客户交谈的人。
我过去的做法是由一个人（产品经理）负责确定错误和新功能的优先级。 PM 根据以下标准决定每个项目是错误还是新功能：
- 如果软件做了一些明显错误的事情（即不是任何人想要或想要的），那么它就是一个错误。
- 如果软件做了与软件设计文档相反的事情，并且没有任何明显的优势，那就是错误。
- 如果软件做了客户（或其他人）不想要的事情，但行为符合设计文档，那么它就是功能请求。
PM 将与工程部门以及客户代表讨论每个错误或功能请求，并在此基础上（以及常识和经验）为每个项目分配优先级。此外，工程师会被要求指出每个项目的大致时间尺度，PM 将使用它来计划下一次迭代。
简而言之，错误是指软件没有按照设计人员的计划执行，而功能请求是指有人希望软件执行未计划的操作。
【讨论】：
SCRUM 方法为这个问题提供了答案。产品负责人决定某事是否是在产品积压列表中创建项目的错误。然后根据项目的优先级将项目安排到迭代中。
【讨论】：
功能性错误和 UI 错误很容易找到，而且争议较少。设计错误是需要通过 BA 和开发团队才能获得意见的错误。与环境相关的问题也应该单独跟踪，并且可能不属于错误类别。
【讨论】：
有很多方法。其中一些：
应完整描述软件要求。如果您发现某些要求没有得到满足，那显然是 bug。
-
您看到满足要求，但以某种不明显的形式。也是bug。但这是开发人员可能会说“一切都很好”并尝试关闭错误的情况。您可以通过以下方式找到您的意见（存在缺陷）：
- 示例如何在同一产品中实现相似的事物。
- 类似产品在类似产品中的工作原理示例（例如 gmail 可用作邮件托管等示例）。
- 询问您的销售和客户关系经理人们对该功能的期望是什么，从最终用户的角度来看它应该如何工作。
- 使用行业最佳实践。
您发现有些东西可行，但可以改进。这也是缺陷:)。它与第 2 点类似，所有建议都对这种情况有用。
附：和其他部门的人讨论、讨论、讨论。
【讨论】：