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