持续部署方法中的QA工程师角色

Question

我找不到自己，因为几乎每一次提交都被部署到生产环境中，所以我没有足够的时间来测试它，我没有“能力”来说明是否正在进行生产，我不确定是否可能遗漏了一些bug等等，我没有自己的测试环境……

到目前为止(在以前的项目中)，我一直在持续交付(team city)，现在是GO CD (最小化交货期)，流水线被分成不同的阶段(其中一个阶段是自动化测试)，我知道这种方法中的自动化对于通过这个流水线非常重要，但我们不能自动化所有的东西，有时会发生意想不到的错误。

我意识到我的描述可能有点夸张，但我现在真的搞不清我的职责是什么。谁能解释一下在持续部署软件工程方法中QA的确切作用是什么？

Answer 1

我看到了三个非常具体的阶段，你作为QA专家的工作可以在所描述的项目中提供帮助。

1. 在需求的最开始阶段，您应该参与创建和定义验收标准。因此，您基本上定义了测试，这些测试应该包含在测试套件中。通过示例来阅读规范。
2. 即使您有CD管道，您也可以有一个阶段，将系统部署在测试系统上，然后测试人员可以开始进行测试。当他们认可这个系统时(或者可能在一段固定的时间后没有发现(相关的) bug)，这个版本被提升到production.
3. Alternative到2。可以创建一个与生产平行的测试系统，这样你就可以测试这个系统，尽管它已经在生产中了。毕竟，尽管快速投入生产是有价值的，但快速发现生产中的错误也有一些严重的价值。

探索性测试真的很有帮助，如果你不知道它，你应该读一读"Explore It“这本书”Explore 2.+3“。

Answer 2

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

如果您正在等待代码提交(无论如何是主分支)来对其进行彻底的测试，那么没有测试驱动程序/开发驱动程序的its too late...CD只是一场等待发生的灾难；及早参与进来，帮助定义测试覆盖率需求，如果必要的话，参与到对这些测试的某种级别的编码中，以确保覆盖了什么。CD之后的差距会小得多，你的信心以及每个人的信心都会更高:)

Martin Fowler有一些关于这个topics...start的有趣文章，请继续阅读- http://www.martinfowler.com/bliki/SelfTestingCode.html

Answer 3

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