手动回归测试是否为旨在持续交付的敏捷团队带来技术负担？

#1 楼

以我的经验，当交付管道中缺乏自动回归成为技术负担时，您只有一个选择。和错误修复。

归结为，如果您的团队一开始没有进行设置，那么您将不得不浪费时间重新测试不需要的东西重新测试或花费额外的时间来构建自动回归。

由于即使在持续的集成管道中，也难以构建UI自动化（应尽可能避免）或进行高级集成测试（ （针对API端点）），直到对功能进行编码为止，安排功能的自动化以在该功能的开发背后运行sprint并不少见-但它仍需要作为计划的一部分。

我的建议如下：


确定手动测试期间自动化候选者的测试区域ing。这些将成为下一个冲刺的自动回归用户案例。
确定不应自动化的测试。这些将成为轻量级手动回归的核心，只有在更改系统的那一部分时才应运行。 / 2和2/3赶上自动化的冲刺时间（您可以将其提高到100％，但这意味着没有新的开发或错误修复）。
一旦赶上了自动回归，则在1/3和1之间/ 2冲刺时间用于维护和向自动回归添加新功能。

当然，这是理想的世界。我必须努力在我所担任的每个测试职位中获得一小部分-这就是我最后的建议：如果您不花时间做正确的事，就会被迫花点时间做完。

#2 楼

这里有很多变量需要考虑。但是这里有些要点都是一样的。例如。我是一个项目的新手，我应该如何自动化？这里要考虑的事情是...


执行手动测试需要花费很长时间吗？
我是否需要在每个sprint期间运行该测试？
它可行自动化吗？例如。技术上可行。在自动化时间和手动运行时间方面的投资回报率。

如果测试是隔离测试或小型错误修复测试，那么我可能会考虑不在每个sprint上运行它。

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

减少手动测试在以前的敏捷项目中，我将为分配给我的每张票设计手动测试。在sprint结束时，我将仔细检查手动测试，看看有什么值得自动化的方法。然后，我将在下一个冲刺中将我的手动和自动化测试自动化并运行，作为回归。此sprint中的新项目将手动进行测试，然后在该sprint结束时考虑进行自动化。

因此，我将在该Sprint中手动进行测试。对于旧内容，我将自动化和手动测试作为回归进行。这导致回归套件逐个冲刺增长。希望有足够的自动化机会可以节省测试时间，让我专注于那些我认为需要保留为手动测试的测试。

我在这里看到的很多文章中，几乎就像人们认为手动测试是错误的，而自动化测试则是好的。恕我直言，一套很好的测试可以并且可能包括这两项。不要沉迷于尝试使一切自动化以消除手动测试。手动测试仍然非常有价值。

在几次迭代之后，我们仍然需要手动进行测试，然后被项目团队标准视为测试的技术债务。我的看法是，技术部门更适用于维护可能不足以满足您需求的自动化测试。您的自动化测试应该可靠且可靠。我不认为手动测试是技术上的负担。您可能会发现自己处于手动测试花费太长时间而无法在sprint中执行的位置，但是我通常不会将其归类为技术债务。

编辑-根据Niel的评论和在技​​术债务象限的链接中，我可以看到手动测试如何产生技术债务。话虽如此，我仍然对尝试使一切自动化并把任何手动测试视为技术债务保持警惕。
我的方法仍然是相同的，将那些对自动化有好处的事情自动化。与运行手动测试相比，不要自动化可能过于复杂或耗时的手动测试。

总结：-


寻找自动化机会，但不要尝试使所有内容自动化。
手动测试在您的测试中占有一席之地。请经常检查测试
，以确保您没有在运行不必要的测试。
不要尝试对所有测试使用单个工具。请改用各种工具。我的意思是，您不会在螺丝钉上使用螺丝刀，而会使用锤子。

#3 楼

这取决于。老实说，我的一部分与问题的语气有关。我担心会进行自动测试，这会损害手动测试，尽管某些类型的软件可能仅通过自动测试就可以。 。而且某些类型的软件开发和测试比其他类型的软件更适合自动化。

但是，自动化的重点不是自动化，而是要释放人们去做只有人们才能做的事情，而某些类型的测试只能由人们来完成。您越深入复杂性堆栈，就越难进行自动化或自动确定测试结果。如果您要测试的东西与其他组件/产品的交互作用不大，则可以自动执行很多测试。但是自动化测试的问题在于，很容易进行测试。

我工作的领域是自动化程度很高的领域，只要没有意外/计划外的事情发生，这就很棒。 。如果发生了某些计划外的事情，您就会遇到问题，因为，谁知道会发生什么呢？自动化可能做错了事，自动化可能没有注意到问题。 。 。

无论如何，关键是，手动测试可能是技术债务。但是，为了自动化测试而进行的自动化测试也是技术上的负担。仅自动化可以安全地自动化的事物，并且不要忽略那些不能自动化但仍应进行测试的事物。

#4 楼

是的，我认为您可以将技术自动化欠缺归咎于技术负担。


我们没有时间进行自动化测试，因此我们可以手动进行


在技术债务象限上听起来像“刻意”和“鲁eck”。 “鲁莽”。去获得一些技能；-)


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


这将是“谨慎”和“故意”听起来像是技术债务。您知道您推迟了它，也许是出于正当的理由，例如我们必须将其运送以获取反馈。现在，您必须偿还债务。

如果实践连续交付是一个战略目标，那么项目中的每个人都应该意识到您正在积累债务。在积压或走廊中使其可视化。就像在每个版本上进行手动测试所花费的时间一样。

更新：

防止技术债务：管理层）意识到债务正在产生。 e2e覆盖率等）

#5 楼

我对您要说的看法是：


太忙了，无法实现自动化
在sprint中难以实现自动化。

我的方法是：


付出更多的努力使人们相信测试的价值。这是一个非常重要的主题，因此在这里我无法深入探讨很多细节。
安排测试时间。对您要测试的所有组合进行一次真正彻底，激烈的测试，并找出需要多长时间。现在做基本的数学运算：每年要花X的频率是X。一旦有了这个数字，就可以节省多少时间和金钱。您需要在此估算中包括“编写自动化所需的时间”。认识到某些测试可能需要比应用程序代码更长的时间。在某些情况下，更长的时间。
推送较小的故事，并进一步分解内容，以便您可以使用应用程序代码进行测试。这并不总是那么容易，但是我已经付出了很多努力，看到了它的成功。

#6 楼

当您处于使用连续交付的情况时，必须在测试或其他方面自动化每个步骤。如果有手动步骤，则没有CD。

您需要在冲刺计划中包括测试（自动化）工作。如果无法在sprint中完成自动测试，则应缩小范围。

每项手动工作都需要花费，每项自动工作都可以带来投资回报，并且是一项投资。

在您敏捷的时候，您应该遵循“流程和工具上的个人和交互”，并确保您的团队在每个sprint中讨论这些问题并采取相应的行动。

#7 楼

我不知道冲刺“紧缩”意味着什么，但我认为这应该是一件好事。

这个问题是关于快速发展的问题，但并未提及质量。如果您所关心的一切都在快速进行，并且自动化测试可以让您比手动测试更快，那么手动测试将阻碍您快速发展。是否将手动测试标记为技术债务是没有意义的。您可能还关心生产可靠，满足其性能目标并且可用的软件。您可能还关心以有效的方式花钱。有时，达到这些目标的最佳方法可能是进行一些手动测试。

#8 楼

我最近在一个团队中工作，该团队花费了大量的手动测试人员时间来根据需求编写测试用例。需求是BDD格式，但是测试用例更多是“传统” /命令式格式（即1.单击左侧的链接2.登录2.go到数据对象页面..）花大量时间只是为了使这些东西井井有条，或解决组织不足的问题。我认为这是直接将需求自动化的过程中可能要花费的时间。毕竟，这有点像BDD。

有时候，工程师可以在发布前手动测试某些东西，然后再也不测试该特定更改，例如微小的错误或已删除的功能。没有理由将那些测试用例保存在可能会或可能不会自动化的内容清单中。

另一种策略是确保测试（自动和手动）重点放在高优先级功能上。例如，最终用户应该能够登录，但是有些功能主要由内部用户使用，而不必一直进行测试。

IMO，软件开发正在变得更快，更可靠，并且如果用户喜欢该产品，那么他们会更容忍一些小错误。一旦编写并部署到生产中的功能，就不会突然从以前的其他功能更改中产生错误。我鼓励手工测试工程师（或在自动化之前进行手工测试的工程师）将精力集中在“产品经理和开发人员忘记了什么会无意中破坏我们的地位？”，“持续进行工作应该优先考虑什么？自动回归？”和“为了使我们的需求与时俱进，我们当前的回归可能需要改变什么？”我们的目标是使您可以相信自己的回归套件可以返回真正的，延迟部署的错误，因此您最大的手动质量检查工作集中在绝对的最新功能和发行版上。

您可能会发现“深度而非深度”的口头禅可以帮助解决这一问题。用户验收测试应绝对涵盖创建，读取，编辑，删除和登录。他们不必覆盖“标题是蓝色和大，提示是小和灰色”。单元测试应该涵盖我们可以在此输入中输入的100种内容，并且您的用户接受测试应使用硒来确保角落办公室的Graybeard先生可以加载页面并打印其TPS报告。它们的运行速度通常会变慢，但是当Bob称其报告丢失时，自动UAT非常适合找出该功能出了哪些问题。