自定义非平凡测试夹具 - 我们是否为它创建用户故事？

Question

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

细节并不重要，但假设我们需要的测试夹具将生成复杂的，相互作用的，状态相关的输入测试向量，并且将寻找复杂的结果序列。

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

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

Answer 1

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