产品负责人和自动化测试

Question

BDD风格开发的一个主张是，它弥合了产品负责人和开发人员之间的差距:产品负责人写了一个故事，可以在一个类似的自动测试“框架”中转换，最终应该会通过。

我想听到的是如何在此之后继续缩小差距:一旦自动化测试到位，您如何帮助产品负责人检查这些测试？或者，仅仅让产品负责人知道测试通过了，而不看测试代码本身就足够了吗？

简而言之，产品负责人应该与实际实现的测试有多亲密，以及您如何让他/她在最初的故事编写之后有效地参与测试？

这个问题背后的原因是双重的。首先，在纸质故事和实现细节之间，一些假设可能潜入其中，让故事作者审查测试可能是无价的。另一方面，该实现也引入了相当多的噪音，并要求PO变得相当技术性(读代码，运行测试)。测试实现是“开发人员的详细信息”，还是请求PO成为该领域的开发人员是公平的？

然后，在大多数情况下，PO只需使用应用程序就可以在不需要自动测试的情况下验证测试。但是，有些故事是“无头的”，只能通过代码进行验证，因此除非PO知道如何读取和运行测试，否则他/她将永远无法声明他验证了该故事是否完成。

Answer 1

我想听到的是如何在此之后继续缩小差距:一旦自动化测试到位，您如何帮助产品负责人检查这些测试？或者，仅仅让产品负责人知道测试通过了，而不看测试代码本身就足够了吗？

产品负责人(或当时戴着产品负责人帽子的人)是以非技术身份行事的。它们只是代表产品的客户和用户。他们不关心这个过程是如何运作的，他们只是负责开发、排序和接受故事。

如果您的产品负责人也是一个开发人员(这是有可能的-这并不是建议反对的方法之一)，那么对他们来说最好的任务也许是充当测试用例的开发人员。如果他们不是开发人员，就和他们一起工作，看看他们想要什么。没有开发经验的人不会从看到测试用例的实现中获得价值。

首先，在纸质故事和实现细节之间，一些假设可能潜入其中，让故事作者审查测试可能是无价的。另一方面，该实现也引入了相当多的噪音，并要求PO变得相当技术性(读代码，运行测试)。测试实现是“开发人员的详细信息”，还是请求PO成为该领域的开发人员是公平的？

这是验证(您的自动化测试)和验证(验收测试和其他由产品负责人进行的测试/评审)之间的区别。

您有测试用例来验证用户故事这一事实是好的。但是，应该由Product来实际验证实现。说你的测试通过了，只能说“我们已经按我们理解的那样实现了这个故事”，而不足以说“这个故事的实现满足了客户和用户的需求”。产品负责人应该对应用程序执行额外的验收测试，以验证故事及其实现。

但是，有些故事是“无头的”，只能通过代码进行验证，因此除非PO知道如何读取和运行测试，否则他/她将永远无法声明他验证了该故事是否完成。

我只想直截了当地说--这些都不是好的用户故事。用户故事的全部意义在于解释用户将如何与系统交互。您可能会开发内部故事来分解用户故事，而这些故事可能是“无头的”。但您将知道，您已经完成了基于通过内部测试和通过验收测试的更大用户体验的测试。

Answer 2

使用一个特性并注销

在我的工作中，当开发人员拿起一件新的作品时，他们做的第一件事就是识别谁是“所有者”。然后，他们向他们快速讨论他们对问题的理解和预期的解决方案。

一旦开发人员完成了实现，他们就会返回“所有者”进行签名。注销涉及到开发人员使用合理的数据在工作系统(他们的开发系统)中显示实现。如果“所有者”满意，他们就签字，实现就完成了。如果“所有者”不满意，则开发人员将确定需要发生哪些更改。然后，他实现了这些，并试图再次签署。