质量保证工程师在持续部署方法中的作用

Question

我找不到自己，因为每次提交几乎立刻被部署到生产中，所以我没有足够的时间来测试它，我没有“权力”来说明是否有什么事情发生，我我不确定是否错过了一些bug等等，我没有自己的测试环境......

直到现在（在之前的项目中）我一直在进行连续交付（团队城市），现在它是GO CD（以最小化交付时间）管道在阶段划分（阶段之一是自动化测试）和I知道这种方法的自动化对于传递这个管道是非常重要的但是我们不能自动化所有事情，有时会发生意外的错误。

我知道我的描述可能有点像chatoic，我真的很困惑，现在我的职责是什么。请问anoyone请解释在持续部署软件工程方法中究竟是什么QA角色？

Answer 1

我看到三个非常具体的阶段，您作为QA专家的工作可以帮助项目如上所述。

1. 在要求的最开始，您应该参与创建和定义验收标准。所以你基本上定义了应该包含在测试套件中的测试。通过示例阅读规范。

2. 即使你有一个CD管道，你也可以拥有一个在测试系统上部署系统的阶段，测试人员可以使用它。当他们批准系统时（或者可能在一段固定的时间之后没有找到（相关的）错误），该版本将被提升为生产。

3. 替代2.测试系统可以与生产并行创建，因此您可以测试系统，尽管它已经在生产中。毕竟快速投入生产具有一定的价值，快速发现生产中的错误也具有一定的价值。

对于积分2. + 3。探索性测试真的很有帮助，如果你不了解它，你应该阅读“探索它”一书

Answer 2

有趣的问题，因为我们的组织正在经历类似的变化。我们意识到CD确实意味着更多的自动化测试和更少的手动测试，但这并不是说QA专家不再需要了。相反，QA应该更多地参与流程的早期阶段，了解用户需求，如何在代码中提供，以及在编写代码之前应如何通过代码测试。正如您所说的那样，也有人认为连续部署中的自动化测试不能涵盖所有内容，并且还需要对生产进行一些测试，但是应该通过在过程早期对测试的关注来最小化在那里发生的错误的严重性。 。此外，使用CD时，修复修复的时间应该要小得多。

如果你正在等待提交代码（无论如何都是主分支）来彻底测试它，那就太晚了......没有TDD / BDD的CD只是等待发生的灾难;尽早参与，帮助定义测试覆盖要求，并在必要时参与编写某些级别的测试，以确保所涉及的内容。 CD之后的差距将会小得多，你的信心以及每个人的信心都会更高：）

Martin Fowler有一些关于这些主题的有趣文章......从这一篇开始并继续阅读 - http://www.martinfowler.com/bliki/SelfTestingCode.html

Answer 3

您的部分工作可能是执行Test Gap Analysis，比较哪些代码更改为测试的代码。目标是找到已更改但未被任何测试覆盖的代码。您的角色可能是实施测试差距分析，监控结果并决定采取哪些对策来减少潜在的测试差距。

Answer 4

恕我直言，质量保证工程师的角色变得更加重要：谁将开发和维护所有这些自动化测试脚本和测试CI / CD所依赖的基础设施？

您可以做的一件事就是尽可能多地从脚本中完成手动操作，以便将其合并到CI / CD中，从而从您的工作中获得更多价值。

实际上，你可能无法实现一切自动化。但是关于你提到的意外错误 - 它真的没有什么可以自动检测它们吗？他们是如何被发现的？无意中还是通过严格的方法？如果这是一种严格的方法 - 这种方法真的不可能实现自动化吗？

提高自动化测试性能（持续时间，覆盖率，资源使用率）对于CI / CD性能也非常重要。