如何在敏捷开发生命周期中适应自动化（系统或E2E）测试？

Question

我是一名自动化测试工程师，在如何在敏捷开发生命周期中适应系统集成测试（E2E）方面从未找到正确的答案。

我们是一个由10个开发人员和2个质量检查人员组成的团队。团队目前正在尝试围绕围绕用户故事的验证和确认的最佳过程建立一个过程的基线。

我们正在遵循的当前过程是静态检查和手动/自动测试的混合。

这是我们的流程： 1.每当故事准备好时，领导都会举行一次故事准备会议，在会议上我们讨论要求，确保每个人都在同一页上，进行估计等； 2.故事出现在板上，并由开发人员选择 3.故事由开发人员实施。该实现还包括必要的单元测试和集成测试。 4.然后将故事进行代码审查 5.一旦通过代码审查，它将被部署并发布到生产中 6.如果生产中出现问题，代码将恢复原状。

QA验证和验证的真正问题在于无法手动测试更改（因为涉及大量微服务）。自动化测试框架还不够成熟，不足以让我们在开发人员实现其代码之前足够快地编写自动化测试。 在这种情况下，我们会在质量上有所妥协，并且在没有正确测试的情况下发布代码。

在这种情况下最好的方法是什么？当前，我们正在将所有这些自动化测试添加到我们的质量检查积压中，并缓慢地创建我们的回归测试包。

任何有关此过程的好的建议都将受到高度赞赏。

Answer 1

这里有一些建议。

  

QA验证和验证的真正问题在于无法手动测试更改（因为涉及许多微服务）。

这是您需要投入时间和精力的地方。一些可能的方法包括：

• 创建模拟微服务
• 创建一个运行微服务版本的测试环境

这两种方法都具有挑战性，但解决后通常会在中长期获得回报。

  

当前，我们将所有这些自动化测试添加到我们的质量检查积压中，并慢慢创建我们的回归测试包。

自动回归测试的价值在于它们具有合理的覆盖范围时（例如，覆盖了50-70％的重要功能）。您可能需要考虑花一些时间来提高覆盖范围，然后再处理新的要求。对团队产出的短期打击将被以下方面抵消：

• 节省手动测试的时间
• 更频繁地运行测试（可能使用持续集成），从而提高质量
• 开发人员对更改代码和重构具有更大的信心

  

自动化测试框架还不够成熟，我们无法在开发人员实现其代码之前足够快地编写自动化测试。

为什么不让开发人员参与编写自动化测试？这将使您能够在测试的创建与新需求的编码之间取得平衡。这可能会导致外观减少团队的产出，但是随着覆盖率的提高，团队将变得越来越有效率。

  

我们是一个由10个开发人员和2个质量检查人员组成的团队

我想您是一个由12人组成的团队，具有开发和质量检查技能。分享知识并分散工作量，直到您拥有可以交付需求和质量的团队为止。

Answer 2

对于我们的团队来说，我们会浪费时间，但是在完成开发故事后，相应的测试自动化故事会进入下一个冲刺。

完成的故事都经过了单元测试，并通过当前的测试自动化脚本运行，以确保我们没有退缩过去的测试/代码。

一旦构建了新测试，我们将通过HP UFT运行完成的代码，如果成功，则将其设置为部署到生产环境。

这可能不是当前完成工作的最佳方法，但它是我们在开始生产之前确保所有内容都经过自动化和测试的一种方法。