我找不到自己，因为每次提交几乎都会立即部署到生产中，所以我没有足够的时间来测试它，我没有“权力”来判断是否正在发生某些事情，我不知道是不是漏掉了一些bug等等，我没有自己的测试环境……
到目前为止（在以前的项目中）我一直在持续交付（团队城市），现在它是 GO CD（以最大限度地减少交货时间），其中管道被划分为阶段（其中一个阶段是自动化测试）和 I知道此方法中的自动化对于通过此管道非常重要，但我们无法自动化所有内容，有时会出现意外错误。
我知道我的描述可能有点啰嗦，我真的很困惑我现在的职责是什么。谁能解释一下持续部署软件工程方法中确切的 QA 角色是什么？
【问题讨论】：
标签： testing process qa continuous-deployment
我看到您作为 QA 专家的工作可以在三个非常具体的阶段为所描述的项目提供帮助。
在需求的最开始，您应该参与创建和定义验收标准。所以你基本上定义了测试，应该包含在测试套件中。通过示例阅读规范。
即使您有 CD 管道，您也可以有一个阶段，将系统部署在测试系统上，测试人员可以尝试一下。当他们批准系统时（或者可能在一段时间后没有发现（相关）错误），版本就会被提升到生产中。
2 的替代方案。可以与生产并行创建一个测试系统，以便您可以测试该系统，尽管它已经在生产中。毕竟，虽然将东西快速投入生产是有一定价值的，但在生产中快速发现错误也有一定的价值。
对于点 2.+3。探索性测试真的很有帮助，如果您不了解它，您应该阅读“探索它”一书
【讨论】：
有趣的问题，因为我们的组织正在经历类似的变化。我们意识到，CD 确实意味着更多的自动化测试和更少的手动测试，但这并不是说不再需要 QA 专家。相反，QA 应该更多地参与流程的早期阶段，了解用户需求、如何在代码中交付，以及在编写代码之前如何通过代码进行测试。正如您所说，人们也承认持续部署中的自动化测试不能涵盖所有内容，并且还需要在生产环境中进行一些测试，但是应该通过在流程早期对测试的关注来最大限度地减少可能发生的错误的严重性.此外，使用 CD 进行修复的时间应该会更短。
如果您正在等待提交代码（无论如何是主分支）来彻底测试它，为时已晚...没有 TDD/BDD 的 CD 只是等待发生的灾难；尽早参与，帮助定义测试覆盖要求，并在必要时参与对这些测试的某些级别进行编码，以确保所覆盖的内容。 CD之后的差距会小很多，你和其他人的信心会更高:)
Martin Fowler 围绕这些主题发表了一些有趣的文章...从这篇文章开始并继续阅读 - http://www.martinfowler.com/bliki/SelfTestingCode.html
【讨论】：
您的部分工作可能是执行Test Gap Analysis，比较更改了哪些代码与测试了哪些代码。目标是找到已更改但未被任何测试覆盖的代码。您的职责可能是实施测试差距分析、监控结果并决定可以采取哪些对策来减少潜在的测试差距。
【讨论】：
恕我直言，QA 工程师的角色变得更加重要：谁来开发和维护 CI/CD 所依赖的所有自动化测试脚本和测试基础设施？
您可以做的其中一件事是尽可能多地从您仍在手动执行的工作中编写脚本，以便将其合并到 CI/CD 中，从而从您的工作中获得更多价值。
实际上，您可能无法自动执行所有操作。但是关于您提到的意外错误 - 真的没有什么可以自动检测到它们吗？它们实际上是如何被发现的？意外还是通过严格的方法？如果这是一种严格的方法，那么这种方法真的不可能自动化吗？
提高自动化测试性能（持续时间、覆盖范围、资源使用）对于 CI/CD 性能也极为重要。
【讨论】：