我曾在多家公司担任过开发人员，最近又在一家新公司从事QA自动化。每个公司都是不同的，我还没有看到一种我真正喜欢的处理方式。质量检查人员常常会说某事是一个问题，而响应或者是"好吧，但它太难了，修复时间太长"，或者是"这不是错误，这是一个功能！"。
是否有人找到一种合理的方法来确定QA所说的错误是否需要修复？

解决方案

我过去的工作方式是由一个人(产品经理)负责对错误和新功能进行优先级排序。 PM根据以下条件决定每个项目是错误还是新功能：

• 如果该软件执行的操作显然是错误的(即不是任何人想要或者想要的)，那么它就是一个错误。
• 如果该软件的行为与该软件的设计文档背道而驰，并且没有明显的优势，那就是一个错误。
• 如果该软件执行的操作不是客户(或者其他人)想要的，但其行为符合设计文档，则是功能请求。

项目经理将与工程人员以及客户代表讨论每个错误或者功能请求，并在此基础上(以及常识和经验)为每个项目分配优先级。另外，工程人员将被要求指出每个项目的大致时间范围，而项目经理将使用它来计划下一次迭代。

简而言之，错误是指软件没有按设计人员的计划执行的工作，而功能请求是指有人希望软件执行未计划的工作。

作为开发人员，我知道我们总是会得到让我们在质量检查中发誓的错误，但是我不认为应该像我们提到的借口所表明的那样，将修复/不修复的决定交给开发人员!!最谦虚的程序员讨厌他/她的代码中出现的错误，因此很容易给我们带来麻烦。我认为测试人员和开发人员之间的一些摩擦是必要的邪恶(前提是我们最终要购买啤酒！)。 "这不是一个缺陷，它是一个功能"是一种常见的反驳，但有时是有效的，这可能就是为什么一个重要的人可能是来自业务方面的人(如果这对工作有意义)。

以我的经验，即使现在无法修复它们，也值得记录，我们始终可以分配滑动优先级，并仅修复至特定水平。定期与测试人员/开发人员一起审查错误也有帮助。

SCRUM方法为该问题提供了答案。产品负责人确定某物是否是在产品积压清单上创建项目的错误。然后，根据项目的优先级将其安排为迭代。

功能错误和UI错误很容易找到并且值得商bat。设计错误是需要经过BA和开发团队才能获得意见的错误。另外，与环境相关的问题也应单独跟踪，并且不能属于错误类别。

有很多方法。他们中有一些：

• 应完整描述软件要求。如果我们发现某些要求没有得到满足，那显然是错误。
• 举例说明类似事物在类似产品中的工作原理(例如gmail可以用作邮件托管等示例)。
• 询问销售和客户关系经理，人们对功能的期望是什么，从最终用户的角度来看，它应该如何工作。
• 使用行业最佳实践。
• 我们会看到一些有效的方法，但可以改进。也是缺陷:)。它与第2点类似，所有放置在该位置的建议对这种情况也很有用。

P.S.并与其他部门的人员进行讨论，讨论和讨论。