testing - 最佳自动化返工量

Question

在功能的开发周期中，功能不断变化，即使在满足所有要求（UI 改进等）之后也是如此。如果您对该功能进行了自动化测试，这些更改可能会破坏您的自动化，您将不得不对其进行返工。但是，如果功能不断变化，那么在每次修订后都重新进行自动化是没有意义的。但是，在某些时候，您必须将其自动化，以便进行回归测试。我们如何才能找到返工自动化的最佳时间？我们如何获得最佳数量？我的团队同意我们对其中一项功能的自动化进行了过度改造。我们犯的一个错误示例是在一次会议之前重新设计自动化，我们向客户展示了该功能以获得客户反馈。我们应该知道客户反馈会导致对该功能进行更多更改。在这种情况下，功能测试应该就足够了。有没有人有任何技巧或经验可以分享？

Answer 1

一般提示是在开始构建之前就“完成”对功能的含义达成共识。

如果在构建过程中您遇到了一些您想添加以改进功能（或其他）的新调整，请不要将它们添加到现有故事中 - 编写一个新故事......并确保您优先考虑它您需要做的其他事情。

这有时但并非总是表明您正在处理太大的功能增量。尝试进一步拆分和细化故事，直到您可以为该功能写下一些非常具体的“完成”定义。考虑在开始构建之前将这些“完成”测试自动化（但不要过火）。

您可能会找到使用说明手册。

Answer 2

根据我的经验，您一直在开发的功能还没有被客户完全理解。

像@adrianh 建议的那样，将功能分成小部分。

给不稳定的客户的另一个提示：让他们首先亲眼看到伪原型，甚至可能在计划会议上（直接将其编码为 html 或更简单的东西，例如原型/绘图工具）。让他们玩。这样，您将更轻松地使用您的功能。