问手动回归测试是否是敏捷团队的技术债，其目标是持续交付？

EN

这里有很多变量需要考虑。但这里还是有一些要点。

手动测试与自动测试这一点本身可能是值得一本书，是最常见的问题之一，我看到。我刚开始做一个项目，我应该自动化什么呢？这里要考虑的是..。

• 执行手动测试需要很长时间吗？
• 我需要在每一次冲刺中运行这个吗？
• 自动化是可行的吗？从技术上讲是可能的。ROI的自动化时间和手动运行时间。

如果测试是孤立的，或者是一个小的bug修复测试，那么我可能会考虑不运行它的每个sprint。自动化也可能没有什么价值。

例如，如果我们正在测试一个使用API的登录屏幕，那么您可能会认为手动测试来检查尽可能多的突发事件是非常耗时的。从好的方面来说，自动化在技术上是简单的。一旦基本测试自动化，您就可以考虑将其转换为数据驱动的测试，这样您的输入和预期的结果将是电子表格中的一行。这样可以在很短的时间内测试1000's的组合。另外，您可以在以后的sprint中添加更多的组合，而不必修改测试本身。

减少以前敏捷项目的手动测试，我会为分配给我的每一张票设计手动测试。在sprint结束时，我将查看手动测试，看看什么是值得自动化的。然后，我将在下一次sprint中自动化并运行我的手动和自动化测试，作为回归。这个sprint中的新项将被手动测试，然后考虑在该sprint结束时实现自动化。

所以，新的东西，我会手动测试在冲刺。对于旧的东西，我运行自动化和手动测试作为回归。这将导致回归套件在sprint的基础上增长。希望有足够的自动化机会可以节省我的测试时间来集中精力于那些我认为需要保留为手动测试的测试。

在我在这里看到的许多帖子中，人们几乎都认为手工测试是错误的，自动化测试是好的。IMHO，一套很好的测试可以并且很可能将两者都包括在内。不要沉迷于试图自动化一切，以消除您的手动测试。手工测试仍然很有价值。

是的，我们仍然有一些东西，在经过几次迭代之后，我们仍然在手工测试，然后根据项目团队标准，它被认为是测试的一个技术债，我在这里的观点是，技术部门更适用于维护自动化测试，而这些测试可能不够健壮，不能满足您的需要。您的自动化测试应该是可靠和健壮的。我不认为人工测试是技术上的债务。您可能会发现您的手动测试花费的时间太长，无法在sprint中执行，但我通常不会将它们归类为技术债务。

编辑-基于Niel的评论和技术债务象限的链接，我可以看到如何手动测试可能招致技术债务。尽管如此，我仍然会谨慎地尝试自动化一切，并将任何手动测试视为技术债务。我的方法仍然是一样的，自动化那些事情是有好处的自动化。与运行手动测试相比，不要将可能过于复杂或耗时的手动测试自动化。

总括而言：

• 寻找自动化的机会，但不要试图使一切自动化。
• 手动测试在您的测试中有一席之地，经常检查您的测试，以确保您没有运行不必要的测试。
• 不要试图在所有测试中使用单一的工具。使用各种工具代替。我是说，你不会在钉子上用螺丝刀，你会用锤子。

那得看情况。老实说，我的一部分关心的是问题的语气。我担心自动化测试的进行有损于手工测试，尽管某些类型的软件可能只对自动化测试做得很好。

是的，你绝对应该尽可能地自动化。有些类型的软件开发和测试比其他类型更适合自动化。

然而，自动化的全部意义不是自动化，而是解放人们去做只有人们能做的事情，而某些类型的测试只能由人们来完成。越深入的复杂性堆栈，就越难自动化，或自动确定测试的结果。如果您正在测试与其他组件/产品没有太多交互的东西，那么您可能能够自动化大量的测试。但是自动化测试的问题是，它很容易调整您的测试。

我在一个领域工作，那里有大量的自动化，而且很棒，只要没有任何意外或意外发生。当没有计划的事情发生时，你可能会遇到问题，因为，谁知道会发生什么呢？自动化可能做错了事情，自动化可能没有注意到问题。。。

无论如何，关键是，可能手工测试是技术上的债务。但是，为了自动化测试而进行的自动化测试也是技术上的负担。只有自动化的事情，可以安全地自动化，不要忽视不能自动化的事情，但仍应进行测试。

是的，我认为你可以把缺乏测试自动化的问题归为技术债务。

我们没有时间进行测试自动化，所以我们手工完成

这听起来像是技术债务象限上的“故意”和“无风险”。

更糟糕的是“我们不知道如何自动化这个测试”，这是“无意的”和“无风险的”。去学点技能吧;-)

我们知道我们应该自动化我们的手动测试脚本

这将是“谨慎的”和“深思熟虑的”，这听起来像是技术债务。你知道你推迟了它，也许是因为一个合理的理由，就像我们为了得到反馈而不得不把它发送出去一样。现在你必须偿还你的债务。

如果实践持续交付是一个战略目标，那么项目中的每个人都应该意识到您正在积累债务。让它视觉化，无论是在积压的还是在走廊。就像在每个版本上花费数小时的手工测试一样。

更新

防止技术债务：

1. 让组织(产品负责人，管理层)意识到债务正在产生。
2. 将技术债务添加到待办事项中，从定义它开始，并在每次迭代时删除它。
3. 将技术债务预防实践添加到您的已完成的定义中(例如创建自动化的e2e覆盖范围，等等)