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

Question

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

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

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

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

Answer 1

• 如果您的“非平凡测试夹具/运行器”估计要花费超过一天的时间才能实现，那么就应该正确地跟踪它的工作，并将其放入您的待办事项中。如果你认为可能需要一个星期或更长时间，那么我会先做一个原型。
• 也许“非平凡的测试夹具/跑步者”本身并没有带来任何业务价值。我猜你是在找技术部。为技术任务/部门写用户故事对我来说总是错误的。将它们作为技术任务放在您的待办事项中。
• 你应该了解你的事业和演员。