testing - 定制非平凡的测试夹具——我们是否为它创建用户故事？

Question

一个相当复杂的库/子系统必须进行集成测试和冒烟测试，为此我们需要开发一个非平凡的测试夹具/运行器。

细节并不重要，但假设我们需要的测试夹具将生成复杂的、交互的、依赖于状态的输入测试向量，并将寻找复杂的结果序列。

测试夹具本身将需要一些重大的开发工作（尽管比子系统本身的工作量要少）。问题是：

• 这个重要的测试夹具是否应该作为迭代的一部分包含在项目计划中？
• 是否应该为此测试夹具创建一组用户故事？
• 如果是这样，用户故事将如何构建？谁将是这里的参与者：运行测试的测试工程师、子系统还是夹具本身？

Answer 1

• 如果您的“非平凡的测试夹具/运行器”估计需要超过一天的时间才能实施，那么应该正确跟踪这项工作并且应该进入您的积压工作。如果您认为这可能需要一周或更长时间，那么我会先做一个原型。
• 可能“非平凡的测试夹具/运行器”本身并没有带来任何商业价值。我假设您正在解决技术部门的问题。为技术任务/部门编写用户故事对我来说总是错误的。将它们作为技术任务放在您的待办事项中。
• 你应该了解你的业务和你的演员。