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

我会在您的测试文件中记录故意不支持的用例/故事/需求/特性,这些特性比规范更可能被定期查阅、更新等。我会在最高级别的测试文件中将每个不支持的特性记录下来,在其中讨论该特性是合适的。如果它是一个完整的用例,我会在验收测试中记录它(例如Cucumber特性文件或RSpec特性规范);如果这是一个细节,我可能会在单元测试中记录下来。

我所说的“文档”是指如果可以的话,我会写一个测试。如果没有,我就评论一下。哪一项取决于功能:

• 对于用户可能希望存在但用户无法访问的功能(例如,根本不存在的链接或菜单项),我会在适当的验收测试文件中,在相关功能的测试旁边写一条注释。

  附带说明:一些测试工具(例如Cucumber和RSpec)还允许您在功能或规范文件中包含实际未运行的场景或示例,因此您可以像注释一样使用它们。我只会在那些禁用的场景/示例在您运行测试时不会产生可能会让某人认为某件事情已损坏或未完成的消息时这样做。例如,RSpec的 pending / skip 大声宣布还有工作要做,所以将其用于从未打算实施的情况可能会很烦人。

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

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

• 如果你想写一个测试,但由于某些原因你不能写,那么总是会有注释——同样,在适当的测试文件中,靠近所实现的相关事物的测试。

你永远不应该测试未定义的行为,通过。。。释义当你测试一种行为时,你就在定义它。

在实践中,要么处理对冲案例有价值,要么就没有价值。如果是这样,那么应该有一个用户故事,作为边缘案例的文档。你不想拥有的是 古老的 用户故事记录 将来 行为,所以在不处理它的故事中记录未定义的行为可能是不可取的。

更一般地说,敏捷开发总是迭代工作。边缘案例发现是迭代工作的一部分:工作带来了知识的增加,知识的增加带来了更多的工作。重要的是在 新 故事,而不是试图一次性处理所有事情。

例如假设我们正在开发Stack Overflow,我们正在做这个故事:

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

团队开发了一个简单的问题搜索,发现我们需要处理封闭的问题。。。我们没有想到!所以我们只是不处理它们(无论实现行为是什么最简单的)。注意,这个故事没有记录任何关于结果中封闭问题的内容。然后我们添加一个新故事

作为一个用户,我想专门搜索封闭的问题,以便找到更多结果

我们开发这个故事,发现更多的边缘案例,然后是更多的故事,等等。

在设计规范中,我们明确指出,这个场景超出了范围,因为系统的设计不是为了以这种方式使用

在产品中使用未记录的功能确实是一种糟糕的做法。

如果您的开发团队遵循BDD/TDD技术 应该 (注意强调)减少这种情况发生的可能性。如果你发现了这种边缘案例,那么你认为你的客户不会?在产品中拥有未经测试和意外的功能可能会影响产品的稳定性。

我建议,如果发现未记录的功能:

1. 了解它是如何引入的(常见原因:一个开发人员认为它可能是一个很好的功能,因为它可能在未来有用,他们不想放弃他们所做的工作!)
2. 与业务分析师和产品所有者讨论该功能。了解他们是否希望在您的产品中有这样的功能。如果他们这样做了,那就很好,记录并测试它。如果他们不这样做,就删除它,因为这可能是一种负担。

您还对跟踪这些边缘案例场景的结果提出了一个问题:

我想实现的是确保我们有一个记录,说明为什么我们决定不支持这种情况,以便我将来可以再次参考。

在编写设计/规范文档时,可以采取的一种方法是对该文档进行版本化。然后,当一个特性/场景被删除时,您可以在文档中的版本更改部分中说明为什么要进行更改。然后,您可以在以后的日期参考此更改历史记录。

然而,我建议使用计划板来跟踪您的用户故事。使用这样的板,你可以在卡上写一个注释(虚拟/物理),解释为什么该功能被删除,稍后也可以参考。