testing - 缺陷与 CR——如何区分

Question

场景:

目前我们正在进行系统和集成测试。每天我们都会收到测试人员提出的许多缺陷。大多数这些缺陷不符合我们的要求。许多场景对开发人员来说都是新的。我们的要求已由企业签署。

有人可以阐明如何区分缺陷与 CR 吗？

Answer 1

所有不是要求的都是变更请求。

但不幸的是，生活并不那么容易，所以请继续阅读。

关于什么是缺陷什么是变更请求的争论在项目中很常见。处理这种情况很困难，因为您经常不得不做出妥协。

我曾看到项目经理被项目经理撤职，因为他们坚持认为所有缺陷实际上都是变更请求。他们经常是对的，但仍然存在行为对计划的整体进展没有帮助。我还看到项目经理通过接受每一个缺陷来自杀，并 build 了城堡，尽管最初不需要和估计的工作量都没有。

我个人总是绝对确保我的经理知道我正在构建最初不需要的功能，这些功能是在缺陷的伪装下出现的。我还确保客户/测试人员知道这是我的观点。但我也很宽容地考虑什么是缺陷。

示例:我最近参与了一个开发金融支付系统的项目，另一位程序员对我说“他们想要的东西令人发指，这不是缺陷，这是 CR!”。我看了看，由于我在这个业务领域的背景，我认为这实际上是非常基本的要求，为此要求 CR 真的很可笑。所以我决定我们修复它而不大惊小怪。

还有以下问题值得考虑:

• 您参与的是固定价格项目吗？您是否仍然拥有资源并通过添加功能而不提示来展示真正的伟大，这会给您带来良好的声誉和 future 的契约(Contract)？
• 如果您接受 CR 作为缺陷，您会受到惩罚吗？少量缺陷是否是 KPI(关键绩效指标)并影响您的职业？
• 需求定义是否一开始就很糟糕，而您接受了它？缺陷中提到的要求是否真的很明显并且可以被认为是隐含的？例如。从未指定金额字段应仅允许数值，但它仍然有意义。
• 您是否接受了要求而不问全局并承担部分责任？
• 客户是否在欺骗您并利用您无法拒绝和拒绝缺陷的能力？

在项目中，我总是努力为客户争取最好的，但要确保我不会受到不当的惩罚。