当测试工程师不断地进行手动测试时，如何编写自动化？

Question

设想情况：

1. Scrum团队由更多的开发人员组成，而不是测试人员。
2. 故事围绕着80%的测试任务进行。
3. 为什么这么多测试？
   • 有几个用户流需要E2E测试；在E2E级别上有一些回归测试。
   • 其中大部分是在上游/用户界面上更改的，因此自动化并不总是一个选项；添加了组件级的新特性，并需要进行特性测试；这些测试的自动化；文档
   • 因为测试和步骤的领域通常包含新的域和复杂的环境设置。

4. 尽管理想情况下，产品经理也会为QA添加技术用户事例，但大多数情况下，此类自动化待办事项不会优先于其他测试任务

由于以上原因，在大多数情况下，QA需要集中精力进行大量的手工测试。因此，自动化成为了后座。有时，这些特性需要如此之快地被推开，以致于自动化成为次要因素。

问题1:在这种情况下，团队如何应对自动化？

问题2:我们所做的事情之一是要求我们的开发人员帮助完成自动化(在他们还没有编写代码的特性上)。然而，有两件事是由于这一点而发生的：

1. QA没有机会改进自动化技能。
2. 由于QA不再进行自动化，(性能评审的标准) QA在评估期间受到负面影响。

如何处理这种矛盾的局面？

Answer 1

你觉得这不可能！不怎么有意思。以下是如何实现这一目标。又短又甜。

1. QAs参与指出了这些故事。您在sprint计划/精化中决定是否需要对这个故事进行任何自动化操作。包括QAs在内的每个人都知道这需要付出多大的努力。所以你要让他们记住这一点。而且，您还提到了自动化需要作为一种验收标准。
2. 从技术上讲，对于所有新特性，您应该编写E2E测试，如果是的话，您不需要不同的回归套装，因为可以定期(通过CI)运行一套新功能。
3. “因为测试和步骤领域通常包含新的域和复杂的环境设置”：您不应该编写任何无法完全自动化的自动化测试。因此，这个场景只保留手动和创建文档。而且，我忘了提到，当您编写自动化--这是您的测试计划--时，不需要编写手动测试计划，而您完全专注于该功能的自动化。有很多方法可以通过工具生成报告。
4. QA不能有一个后座:因为在技术上，敏捷中没有指定的QA角色。所有这些都是团队成员，如果QA通道中的故事越来越重，那么开发人员就必须加强并清除QA通道。而且，如果你在没有给QA足够的时间的情况下把故事推出来，或者QA不能完成它们，并且希望它们退出，那么当然，故事指向是有问题的。它们没有指向正确的方向。
5. 选择与应用程序体系结构相匹配的自动化工具和语言。例如，如果您是Java商店，请选择Java相关工具(Selenium)，这样，如果QA落后于Dev，则可以轻松地获取和完成、重新修补或编写一些自动化测试用例。这个场景还将包括QA自动化技能的改进，因为他们可以很容易地从开发人员那里获得帮助来编写代码等等。它大大加快了这一进程。

编辑:确保QA和Devs的比例是正确的，否则QA总是落后的，因为有时编写自动化比编写应用程序要重。

Answer 2

如果你的管理层如此专注于短时间的回报，它不会投资于提高你的技能来提高你的生产力--无论如何，你应该在你自己的空闲时间去做。所有的工具和文档都是免费的，你只需投入你的时间。

当然，您的进度会比较慢，但是经过一段时间之后，您应该能够展示一些结果，向您的经理证明，对测试自动化提供更多的支持对于公司来说是很好的投资。或者，如果没有，你获得了技能，你可以申请到一个不同的公司，有更好的未来(对公司和你)。

俗话说:如果你不能改变你的公司--改变你的公司(意思是:用你的脚投票，为另一个公司工作)。

Answer 3

您需要重新定义“已完成”的定义用于票证。在手动测试、文档和自动化完成之前，票证是不完整的。项目经理一开始可能会心烦意乱，但当你告诉他们提高质量的手段时，赢得争论并不难。