如何在 Scrum/敏捷/TDD 流程中记录未定义的行为 [关闭]

Posted 2023-02-23

【中文标题】如何在 Scrum/敏捷/TDD 流程中记录未定义的行为 [关闭]

【英文标题】：How to document undefined behaviour in the Scrum/agile/TDD process [closed]

【发布时间】：2014-07-22 08:20:01

【问题描述】：

我们目前使用的是半敏捷流程，我们仍在编写设计/规范文档并在开发过程中对其进行更新。

当我们细化我们的需求时，我们经常遇到边缘情况，我们认为处理它并不重要，因此我们不会为该用例编写任何代码，也不会对其进行测试。在设计规范中，我们明确指出这种情况超出了范围，因为系统并非设计为以这种方式使用。

在更成熟的敏捷过程中，测试应该充当系统预期行为的规范，但是您将如何记录某个场景明确超出范围这一事实，而不仅仅是不小心错过了？

澄清一下，这是我试图避免的情况：我们已经讨论了一个场景并决定我们不会处理它，因为它没有意义。后来，当有人尝试编写用户指南，或进行培训课程，或客户致电服务台时，出现完全相同的情况，所以他们问我系统如何处理它，我想“我记得一年前讨论过这个，但没有测试它。也许它错过了计划，或者我们认为它不是一个明智的用例，或者也许有一个微妙的原因你不能真正做到曾经陷入那种情况”，所以我不得不尝试搜索旧的 Skype 聊天或电子邮件以找出答案。我想要实现的是确保我们记录了为什么我们决定不支持该方案，以便我将来可以参考它。目前我把它放在规范中，每个人都可以看到它。

【问题讨论】：

这个问题是不是自相矛盾？什么是记录在案的未定义行为？

我投票结束这个问题，因为它不是关于编程的

【参考方案1】：

我会在您的测试文件中记录故意不支持的用例/故事/需求/功能，这些文件比规范更有可能被定期查阅、更新等。我会在最适合讨论该功能的***别测试文件中记录每个不受支持的功能。如果它是一个完整的用例，我会在验收测试中记录它（例如 Cucumber 功能文件或 RSpec 功能规范）；如果这是一个细节，我可能会在单元测试中记录它。

“文档”是指如果可以的话，我会编写一个测试。如果没有，我只会发表评论。哪一个取决于功能：

对于用户可能希望出现但用户无法访问的功能（例如根本不存在的链接或菜单项），我会在适当的地方写下评论验收测试文件，在确实存在的相关功能的测试旁边。

旁注：一些测试工具（例如 Cucumber 和 RSpec）还允许您在功能或规范文件中包含实际未运行的场景或示例，因此您可以像 cmets 一样使用它们。只有当您运行测试时那些禁用的场景/示例没有导致消息可能使某人认为某些东西已损坏或未完成，我才会这样做。例如，RSpec 的pending/skip 大声宣布还有工作要做，因此在从未打算实施的情况下使用它可能会很烦人。

对于您决定不处理但好奇的用户可能会遇到的情况（例如，在字段中输入无效值或编辑 URL 以访问他们无权访问的页面)，不要只是忽略它们，以最简洁的方式处理它们：悄悄地清除无效值，将用户重定向到主页等。在测试中记录此行为，也许用注释解释你为什么不这样做做任何更有帮助的事情。这不是很多额外的工作，而且比向用户显示错误页面或其他令人担忧的行为要好得多。

对于类似前面的情况，但由于某种原因您决定不处理或根本找不到处理方法，您仍然可以编写一个记录该情况的测试，例如输入一些无效的将值放入表单会导致 HTTP 500。

如果您想编写一个测试，但由于某种原因您不能，那么总有 cmets -- 同样，在适当的测试文件中，靠近已实现的相关事物的测试。

【参考方案2】：

您永远不应该通过...定义来测试未定义的行为。测试行为的那一刻，就是在定义它。

在实践中，处理对冲案件要么有价值，要么没有价值。如果是，那么应该有一个用户故事，作为该边缘案例的文档。您不希望拥有一个记录未来行为的旧用户故事，因此可能不建议在不处理它的故事中记录未定义的行为。

更一般地说，敏捷开发总是以迭代方式工作。边缘案例发现是迭代工作的一部分：随着工作的增加，知识也随之增加，随着知识的增加，工作也随之增加。重要的是在新故事中捕捉这些发现，而不是试图一次性处理所有事情。

例如。假设我们正在开发 Stack Overflow，我们正在做这个故事：

作为用户，我想搜索问题以便找到它们

团队开发了一个简单的问题搜索，并发现我们需要处理封闭的问题......我们没有想到这一点！所以我们根本不处理它们（无论最简单的实现行为是什么）。请注意，该故事没有记录任何关于结果中已关闭问题的内容。然后我们添加一个新故事

作为用户，我想专门搜索已关闭的问题，以便找到更多结果

我们开发这个故事，并找到更多的边缘案例，然后是更多的故事，等等。

【讨论】：

嗯，我要做的是确保系统的参数定义好，所以如果有人问“它如何处理这种情况”，我们可以找到我们的记录做出未定义行为的决定，而不必记住或搜索电子邮件以发现我们讨论过一次并决定不处理它。也许一旦我进入更敏捷的思维模式，我就会不再那样想了。

@Andy 我想说的是你的故事应该只说明目的是什么，并且参数应该自动适合它。因此，每个故事都暗示要完成的工作是“对所述问题的最简单可能的解决方案”。如果出现任何复杂情况，那就是一个新故事，有一个新问题要解决（绝不是解决方案）。

【参考方案3】：

在设计规范中，我们明确声明此方案超出范围，因为系统并非设计为以这种方式使用

在您的产品中包含未记录的功能确实是一种不好的做法。

如果您的开发团队遵循 BDD/TDD 技术，他们应该（注意强调）降低发生这种情况的可能性。如果您发现了这种极端情况，那么是什么让您认为您的客户不会？产品中包含未经测试的意外功能可能会影响产品的稳定性。

如果发现未记录的功能，我建议：

了解它是如何引入的（常见原因：开发人员认为它可能是一个很好的功能，因为它可能在未来很有用，并且他们不想丢弃他们制作的工作！） 与您的业务分析师和产品负责人讨论该功能。了解他们是否希望您的产品具有这样的功能。如果他们这样做了，那就太好了，记录并测试它。如果他们不这样做，请将其删除，因为这可能是一种责任。

您还对跟踪这些极端情况的结果有疑问：

我想要实现的是确保我们记录了我们决定不支持该方案的原因，以便我将来可以参考它。

在编写设计/规范文档时，您可以采取的一种方法是对该文档进行版本化。然后，当删除某个功能/场景时，您可以在文档的版本更改部分中注明进行更改的原因。然后，您可以在以后参考此更改历史记录。

不过，我建议您使用规划板来跟踪您的用户故事。使用这样的板，您可以在卡片（虚拟/物理）上写一个注释，解释为什么该功能被删除，也可以在以后参考。