Question

我正在开发一个相当大的现有代码库，其中创建了SBE规范来定义产品的行为。

目前大约有450个场景，而且这个数字正在增长，每个新功能都会添加到代码库中。

与传统的单行要求声明相比，由于SBE规范的冗长性质，很难高度理解系统的功能。例如，这些故事目前共有46,830个单词：

$ find src/main/resources/stories/ -name *.story | xargs cat | wc -w
   46830

另一个问题是我们正在使用gerrit code review工具进行故事协作，这导致团队之间的formalized communication。

问题1 ：SBE应该是一个完整而全面的回归测试套件（example）吗？或者，他们应该只专注于每个sprint所需的关键功能吗？

问题2 ：正如答案here所述，管理大型项目故事所需的问题跟踪器等工具是什么？

Answer 1

通常，验收测试和行为测试侧重于确保价值的实现，因为它们本身就是一种黑盒测试形式。

所以对于1.答案是否定的，它们不应该是完整的。他们应该确保产生价值的外部行为不会消退。

关于2.我会避免使用这些工具，因为它们很难查询以获取基于时间的信息：通常像Rally或Version one这样的敏捷工具能够烧掉图表，让你白天减速和速度图表。使用bug跟踪器获取敏捷的轨道和敏捷工具！