为外部客户开发时用户验收测试缺陷分类

Question

我参与了一个大型开发项目，其中我们(一个非常小的初创公司)正在为一个外部客户(一个非常大的公司)开发。

我们最近收到了他们的第一个输出来自UAT测试的一个相当小的迭代，其中列出了12‘缺陷’，分为三类:低，中等和高。

我们面临的问题是，这份清单中的每一件事是否都应该被记录为“缺陷”--他们发现的一些问题会被更好地描述为改进，甚至是“良好的拥有”，还有一些我们认为根本不是缺陷。

他们客户的QA负责人说，对他们来说，把他们认为是缺陷的每一个问题都贴上标签是标准的，然而，我们对此感到有点不舒服。虽然这段关系很好，但我们并不认为这有什么大问题，但我们担心，如果这种关系在未来受到损害，这些“缺陷”的清单可能会给我们带来代价。

我们不想让人觉得困难，也不想把事情看得太个人化，我们很高兴做出所有的改变，但是我们有点担心，特别是在我们的关系中存在着不平衡的力量平衡。

我们是不是偏执狂了？或者，我们是否可以通过同意这种分类来解决问题呢？

Answer 1

你可以说“报告的客户问题”或其他任何东西，如果它让人们高兴。我要说的是"Bug“，因为它有着如此悠久的历史，是行业标准术语。在全新的bug列表中，您可能期望修复接近100%的错误。但是，添加到列表中的bug越多，您希望修复的就越少。事实上，大多数bug跟踪工具都允许您关闭bug，原因有:重复、特性请求、无法复制、等待、需要额外的反馈等等。

重要的是捕捉反馈和对反馈采取的行动。我们非常清楚地向客户表明，我们可以选择修复哪些bug以及实现哪些功能。我们这样做是基于我们认为能让大多数客户最高兴的事情，但这是我们的选择。

尊重地提供对这些错误的反馈。如果你不打算修复什么，告诉他们为什么。有时可以说，您还没有准备好对给定的bug提交特定的解决方案。或者一个bug超出了这个版本(或者这个产品)的范围。或者说，通过改进文档(例如调整UI或文档，使用户不做导致错误的事情)，系统工作方式中的一个bug可能是“修复”的。显然，如果您修复了一些bug，您的客户将更加开放，您不修复他人。

如果客户在使用您的软件时遇到重大问题，那么没有错误命名系统会使他们感到高兴。如果他们喜欢你的软件，名字也不重要。做一个伟大的软件，尊重你的客户，不要被错误类别所困扰。

Answer 2

你需要理解的是，在大公司中，需要有一个明确的过程，否则每个人都会做自己的事情，而A团队不知道B团队对“缺陷”的定义是什么。因此，可能有一个相当严格的分类系统，这样团队就可以立即知道其他团队在谈论什么。

然而，这并不意味着这些术语在您的组织中有任何意义。事实上，仅仅因为对他们来说这是一个高优先级并不一定意味着它必须是一个高度优先对你(我知道这是可怕的考虑，因为他们可能是一个巨大的客户)。在他们看来，无论什么时候做了意想不到的事情，这都是一个缺陷，不管这个意外是设计的还是没有的。另外，如果你有一个复杂的软件，你很容易对事情应该如何运作感到困惑。我希望我们的bug跟踪软件有一个关闭的理由，“你做得不对。”

例如，上周在我的公司(我们不是一个定制的开发商店，我们有实际的软件产品)，一个客户通过他们的帐户代表提交了一个bug，并且表现得好像是一个实际的错误，也就是说，该产品没有正常工作。我解释说，该产品按照设计和合同工作，他们想要的是一种改进。对于管理层来说，这并不像"bug“或”缺陷“那么可怕。

只需确保您没有“修复”超出项目范围的缺陷。这就是你如何得到抱怨的客户，他们认为你会免费做每件事。

Answer 3

是的，您可以通过盲目地接受bugs/defects/features/they-don't-know-what-they-want/requirements.的客户分类来自找麻烦。正如Greg指出的那样，有些情况下“你做错了”是问题所在，而不是实际的软件。

这些最常出现的原因是，定义需求的人每天都不使用软件。帮助缓解这一状况的一件事是建立一个渠道，以获得用户的直接反馈，而不是通过可持续性/支持小组。

理想情况下，您的团队将有机会与进入缺陷的个人进行交谈，这样您就可以提取细节。通常情况下，简单地与个人交谈并解释为什么某件事情会做它所做的事情(甚至说要求说它必须这样做)可以使他们回到缺陷中去。