对等测试，就像代码检查一样

是否有人实践功能测试的“代码审查”过程？您觉得有用吗？我目前的雇主使用SCRUM的方式，我们将功能测试作为任何给定冲刺中“必须完成”工作的一部分。

我们还练习SCRUM。和您一样，我们也将功能测试作为完成的一部分包含在内。

根据我的经验，我发现它非常有用。通过强制执行功能测试，我们已大大减少了代码中的错误数量。

关于代码审查的第二点好处是，它为您提供了有关实际功能的另一种视图，并确保100％确保其与客户/客户的需求相符。曾经有几次有人去检查代码和功能，而那个人去了…… “等等，这是不对的……”结果证明，实现代码的人只是误解了一些东西。

是的，天哪（我尽量不要对SO使用专有名词; p）。同行评审您的功能测试基本上就是同行评审您的需求和分析，这非常重要，如果您使用像黄瓜这样的BDD语言，您也可以让非程序员参与！

当最终用户发现我们的功能测试有问题时，这真是太棒了，它使他们感到开发过程中的很大一部分“我也可以阅读代码！”

这对我来说很有意义。您编写的任何代码都应该由他人查看，即使该代码仅在内部使用，也永远不会由客户运行。

在测试中使用如此重的方法，测试的审查变得更加重要，可能是必需的，有时甚至更重要的是，对代码本身的审查，因为通常认为它可以用满足相同自动化要求的任何代码来代替测试结果。

回顾测试的正确性是一个方面，它们足够完整且准确/具有代表性也很重要。

缺少这一点是使这些方法对于外部审阅者显得草率的原因之一。

您可以进行配对检查！

配对检查是：

在创作和文档制作周期中，对文档进行积极和非正式的审查。

此方法在测试中效果很好的原因是：

1. 您可以经常用一对以上的眼睛检查需求或文档。
2. 您不仅可以让开发人员参与其中，还可以：尝试使用测试主管的BA，使用PM的BA，使用Dev的BA。
3. 您可以将重排会议设置为敏捷流程的一部分–确保认真对待团队成员的坚定承诺。
4. 您可以将这些配对检查用作建立和谐关系和与利益相关者进行交流的一部分。进行对话！

我们至少会不定期地对功能测试进行同行评审，并且强烈建议我们的组织对所有代码进行评审。

我建议根据您的审查目标选择您的审查者。开发人员（主要是为了代码质量）和另一个测试人员（主要是为了测试覆盖率）可能最好对编码的测试进行审查。没有代码的测试（使用工具，例如，数据驱动的测试）可能最好仅由另一位测试人员进行复查。同行评审也是鼓励测试人员互相学习的好方法。