边缘案例的验收标准

我是敏捷团队的产品负责人。我在进行PO验收测试时，通常会记下一些极端情况的注释。对于我来说，发现一些东西然后将其传回给开发人员并不罕见。当我拒绝他的故事时，我正从一位开发人员那里退缩。他说这是不公平的，因为我没有详细说明极端情况以及程序在接受标准中应如何回应，因为他倾向于仅针对我在故事中描述的内容进行编码。我鼓励他问我，因为他在编写代码时碰到了任何极端情况，但是他认为思考极端情况，我的事不是我的工作，我应该为下一个冲刺创造新的故事。

在我的辩护中，直到故事实现后，我才知道他的故事设计，因此很难遍历所有可能性（配置将存储在数据库还是属性文件中？）。为了简单起见，可以说我们有一个故事要为计算器应用添加除法。在理想的SCRUM世界中，我是否有责任在接受标准上添加“零分手处理”，还是他应该在开发过程中认真研究这些情况，以使应用程序不会在5/0上崩溃？需要明确的是，在这种情况下，如果应用程序在5/0时硬崩溃，我将不接受，但如果它记录日志，打印DIV0或其他任何方式来处理错误，则我将通过。不会崩溃

我认为答案是你们俩都应该考虑自己的一些极端情况。作为开发人员，他应该处理特定于数据的极端情况，例如应用程序是否因任何给定的用户输入而崩溃，因此5/0当然属于这一部分。当作为用户交互的一部分而给出的输入导致无效内容时，开发人员应询问您认为适当的错误消息。

您所占的份额是事物的业务方面。如果不允许用户帐户使用除法按钮，计算器应如何处理？当允许帐户使用Mod操作但无权使用除法功能时，该如何处理？

我认为您需要传达的重要信息是，你们都在同一个团队中，并且得到所有团队成员的接受。如果产品不完整，则产品不完整，应归咎于团队，而不是任何给定成员。

团队需要一起工作，而不是拥有“不是我的工作，不是我的责任”类型的态度/口头禅。

接受标准的形式为：

• 业务验收
• 质量保证验收

通常，业务验收通常会回答以下问题：

• 实现的功能是否可以实现我想要的功能？

该功能将具有许多面向业务的需求，例如，如果我按此按钮，我希望此操作会发生。它将列出预期的业务场景和预期的行为，但不会涵盖所有可能的情况。

期望应该在迭代之前定义业务需求，以便质量保证可以针对非业务需求开发任何技术。质量保证应根据需要开发破坏性案例和边缘案例。

在开始任何故事工作之前，应对这两组需求进行审查，以便可以对工作单元进行正式的评估和承诺。完成此操作后，即可处理功能/故事。在这一点上，每个人都清楚要从业务和技术角度交付什么。

一旦业务和质量保证团队成员在该故事上签字，该故事将被最终接受。对于业务接受和质量保证接受，这都应该在迭代过程中发生。这是完成（DoD）的定义，表示可以开始其他故事工作。

任何新发现可能会记录为缺陷或其他故事的加成。在理想世界中，这永远不会发生，但实际上，在处理功能/故事时通常会发生一些“发现”。这是自然的。

该小组应共同努力（商业，QA，开发者）以哈希任何模糊不清的发现类型的需求。如果这很敏捷，那么他们都应该坐在同一张桌子上，以促进沟通和快速解决可能出现的任何问题。它应该是这样的：

质量检查：

“嘿，开发人员，我们应该处理这种特殊情况。我发现，如果我输入此数据，则会出现错误。”

DEV：

“这没有包含在任何要求中，但是我们可以添加一些其他功能来解决此问题。好吧，业务人员，您希望应用程序在这种情况下如何运行？”

商业：

“让我们显示我们的标准错误消息，然后让用户针对这种情况再次尝试。那么会付出多少额外的努力？”

DEV：

“这很容易，只需再花一两个小时。我可以承诺进行这次迭代。质量检查人员，请针对这种情况更新您的接受条件，我们不需要其他内容。谢谢！”

或者，如果工作量很大，则将新故事添加到积压中。团队仍然可以接受满足所有原始要求的原始故事，然后在下一次迭代中获取重要故事。

编写面对错误或模棱两可的输入时表现稳定的软件是软件开发人员工作的重要组成部分。

如果您的开发人员不这样认为，请在要求规范中包括明确说明该要求的其他非功能性要求，并为您的开发人员提供测试过程的示例，以便他们可以在提交最终结果之前自行应用该过程代码进行审查。

无论如何，验收测试应该是任何需求文档的重要组成部分。如果一项要求也没有说明接受标准，那实际上不是一项要求。这是一个愿望。

这里发生的事情是您已经发现了价值。编写故事（和接受标准）或编写代码的时间没有考虑输入值。如果这不是接受标准的一部分，那么您实际上就没有拒绝故事的依据。

我们将对我的团队做的是：

1. 创建一个详细说明预期行为和实际行为的错误。
2. 更新接受标准，以便记录新发现的要求。
3. 在下一次迭代中将Bug与所有其他Stories和Bug一起排列优先级。

这样做的好处是，您不得不考虑是否要修复此错误是下一个最重要的事情。修复可能不够重要，但考虑其价值也很重要。

当然，您仍然需要找到一种方法来鼓励开发人员（和您自己）提前探索这些极端情况。如果您的开发团队不花时间来分解故事，则鼓励他们在开始进行故事之前进行详细的计划会议。

一些观察：

...当我拒绝他的故事时

我不知道您的工作文化或工作流程，但对我来说，拒绝一个故事是一个严峻的步骤。如果我是开发人员，那么我也会对此予以反击，因为这是一个记录在案的行为，对我和团队都有不良影响。

他说这是不公平的，因为我没有具体说明极端情况。

期望您知道所有极端情况对他来说是不公平的。但是同时，您对他的期望也不公平。每项变更都有风险，随着问题的发现，你们都需要团队合作共同解决这些问题。

在他实现故事之前，我不知道他的故事设计

您不必知道设计。了解设计以便对哪些故事更容易或更难进行积压管理进行初步的教育猜测可能会有所帮助。但是在编写故事时，请避免让开发人员陷入您的设计中。当您只是用于PO的声控键盘时，它将为您带来所有乐趣。

听起来你们应该努力改进流程并进行一些团队建设。我可能会建议一些有关流程的内容：

• 建议开发人员在故事中花些时间来掩盖发现的边缘情况。哎呀，使其成为每个用户故事的一部分。通过引入0个新错误的目标，这很容易辩解。问题在于，开发人员当前并未对此进行规划。当您发现问题时，他没时间了。无论哪种方式都需要时间，因此将其放在计划中可见的故事中。
• 完成测试（并感谢您的测试！）后，向开发人员发送发现问题的列表。解决这些问题将违反“满意的情况”。
• 如果仍然无法解决或发现太晚，则根据是否可以满足用例来决定是否需要推送故事。发生已知问题和解决方法。在发行说明中披露了它们，并创建了新的故事来修复它们。
• 如果在流程中有一个特别的地方会产生回推，请更改流程！毕竟，过程改进是Scrum的一部分。例如，如果您的开发人员在拒绝该故事时感到沮丧，那么请向团队建议一个流程更改，以使拒绝不会触发修复。在完成并拒绝之前进行测试和修复。
• 与团队合作，以及他们产生的成果，并尽最大可能利用它。他们做的不完美，您也不做。所以为此做计划。我的团队通常都是开发人员，因此我们在每个冲刺中都有一个计划外支持用户故事，以应对紧急问题...为无法计划的计划。

要求应简洁明了。如果不是，那么就发生在您身上的事。这是您的错，指定要求时最糟糕的事情就是假设事情。

您的具体示例是关于零除。如果您未指定要记录错误，则不要抱怨开发人员是否将结果打印为100。

但是在这种情况下，我只会填补缺失的空白，然后将其传递给开发人员。毕竟，需求中的错误确实会发生。