如果你是一名软件质量保障人员（QA），那么是时候去找一份新的工作了（或者get新技能准备升级转型）。绝大多数情况下，软件开发过程包括如下几个主要活动：

o    进行需求分析

o    创建软件产品的规格说明书

o    构建软件

o    软件（或服务）质量调查

o    发现、修复缺陷

o    部署软件到实际生产环境

在大多数机构或公司里，软件开发过程主要遵循一个或多个开发模型，例如瀑布模型或敏捷模型。在瀑布模型中，测试活动一般都在后期进行。软件开发完成后，缺陷被QA团队找出，然后再被修复。后两个活动不断循环和重复，指导管理者认为软件可以被公开发布为止。

在敏捷模型中，包括QA在内的个人和团队在一起紧密工作，在一种持续的基础上不断发布、更新软件，而在某个时间一起部署整个软件。DevOps，就像我们在之前的文章中已经提到过的，是下一代的敏捷开发模型。敏捷是一种在软件开发中不断思考的方式，而DevOps则更进一步发展，是实现组织内开发哲学的具体开发文化的变革。

而且这种实现方式消除了QA作为组织中一个单独实体的存在意义，将质量保障的工作分散给不同的开发团队，尽管许多人认为原来的质量保障的规则仍然需要通过这种或其它的方式存在。

过去对DevOps中QA的理解

其中一种常见的观点认为DevOps位于开发团队、运营团队、QA团队的中心（见上韦恩图）：“一方面，QA团队和开发团队一起工作，尽量将他们的测试融入到系统的持续集成中。测试必须做到没有人力干预，独立产生他们自己的测试数据。另一方面，QA团队和运营团队一起合作完成监控工具，也可能一起不断对产品进行Smoke Test。有一种可能是运营团队在开发系统备份和恢复、部署回滚的脚本或者灾难恢复的脚本。”

在NeoTYS的Tim Hinds则从不同的角度看待这个问题，他认为“DevOps QA”的作用是预防缺陷的发生而不是检测缺陷：“QA在组织中担任非常关键的角色，因为他们有足够的能力和权限能够在系统正常工作时将其发布出去并且在发现系统不工作时将其回滚。这和10年前的QA团队的观念相比是非常不同的，当时认为QA团队的主要职责是发现缺陷。今天QA团队则被要求避免缺陷被 给公众。”

但是客观的说，上述的观点都是错误的。

为什么DevOps不需要（传统型的）QA

DevOps通常使用持续集成（CI）和持续交付（CD）。在持续集成中，开发人员利用各种持续集成工具来不断将代码整合到共享代码库中，甚至每天多次提交，而且DevOps依赖自动化来确保版本质量。如果想要进行持续角度，就不能有人工干预，这样才能确保在任何一个时间都可以发布代码库中的任何一段代码的任何一个版本。

基本上，传统的QA不可能在完整的持续集成/持续交付的环境中工作。在旧的结构中，软件产品的质量保障的责任是在QA的手里、而今天，它则是DevOps的开发文化和开发哲学的一部分——所有开发人员都有这个责任而非仅仅组织中的一个独立的团队拥有这个责任。

具体来说，DevOps需要使用诸如BUGtrack、JIRA和Github等产品和工具来不断汇总和报告软件中的错误和缺陷。Selenium、Cucumber、Junit、TestNG和JMeter等自动测试工具则用于管理、执行和度量功能测试等。

最后总结一下，如果在开发团队和运营团队中间还阻隔了一层人员，那么你就不能无缝执行持续集成和持续交付，也就不能进行DevOps。因此，要想正确的运行DevOps操作，则根本不能拥有（传统型的）QA团队。

QA的未来

那么对于QA工作者来说他们之后会怎么样呢？作为曾经美国最最幸福的工作之一的QA，随着越来越多的组织使用DevOps，传统型的QA工作者们的位置会变得越来越冗余。

根据美国劳工统计局（BLS）的报告，软件质量工程师是高新技术职业中增长速度预计将比平均水平慢的职业之一：

然而，美国劳工统计局的统计数字可能太泛化了因此劳工局还没有将DevOps认定为一个独立的职业：

作为证据，仅仅看一下Google趋势中搜索数据的相对数量就会发现“sqa jobs”的搜索数量正在缓慢下降然而“devops jobs”的搜索数量则在迅速增长：

很明显，QA的趋势看起来绝对不算好。⊙﹏⊙!（ASAF YIGAL原创）

如果你是一名软件质量保障人员（QA），那么是时候去找一份新的工作了（或者get新技能准备升级转型）。绝大多数情况下，软件开发过程包括如下几个主要活动：

o    进行需求分析

o    创建软件产品的规格说明书

o    构建软件

o    软件（或服务）质量调查

o    发现、修复缺陷

o    部署软件到实际生产环境

在大多数机构或公司里，软件开发过程主要遵循一个或多个开发模型，例如瀑布模型或敏捷模型。在瀑布模型中，测试活动一般都在后期进行。软件开发完成后，缺陷被QA团队找出，然后再被修复。后两个活动不断循环和重复，指导管理者认为软件可以被公开发布为止。

在敏捷模型中，包括QA在内的个人和团队在一起紧密工作，在一种持续的基础上不断发布、更新软件，而在某个时间一起部署整个软件。DevOps，就像我们在之前的文章中已经提到过的，是下一代的敏捷开发模型。敏捷是一种在软件开发中不断思考的方式，而DevOps则更进一步发展，是实现组织内开发哲学的具体开发文化的变革。

而且这种实现方式消除了QA作为组织中一个单独实体的存在意义，将质量保障的工作分散给不同的开发团队，尽管许多人认为原来的质量保障的规则仍然需要通过这种或其它的方式存在。

过去对DevOps中QA的理解

其中一种常见的观点认为DevOps位于开发团队、运营团队、QA团队的中心（见上韦恩图）：“一方面，QA团队和开发团队一起工作，尽量将他们的测试融入到系统的持续集成中。测试必须做到没有人力干预，独立产生他们自己的测试数据。另一方面，QA团队和运营团队一起合作完成监控工具，也可能一起不断对产品进行Smoke Test。有一种可能是运营团队在开发系统备份和恢复、部署回滚的脚本或者灾难恢复的脚本。”

在NeoTYS的Tim Hinds则从不同的角度看待这个问题，他认为“DevOps QA”的作用是预防缺陷的发生而不是检测缺陷：“QA在组织中担任非常关键的角色，因为他们有足够的能力和权限能够在系统正常工作时将其发布出去并且在发现系统不工作时将其回滚。这和10年前的QA团队的观念相比是非常不同的，当时认为QA团队的主要职责是发现缺陷。今天QA团队则被要求避免缺陷被 给公众。”

但是客观的说，上述的观点都是错误的。

为什么DevOps不需要（传统型的）QA

DevOps通常使用持续集成（CI）和持续交付（CD）。在持续集成中，开发人员利用各种持续集成工具来不断将代码整合到共享代码库中，甚至每天多次提交，而且DevOps依赖自动化来确保版本质量。如果想要进行持续角度，就不能有人工干预，这样才能确保在任何一个时间都可以发布代码库中的任何一段代码的任何一个版本。

基本上，传统的QA不可能在完整的持续集成/持续交付的环境中工作。在旧的结构中，软件产品的质量保障的责任是在QA的手里、而今天，它则是DevOps的开发文化和开发哲学的一部分——所有开发人员都有这个责任而非仅仅组织中的一个独立的团队拥有这个责任。

具体来说，DevOps需要使用诸如BUGtrack、JIRA和Github等产品和工具来不断汇总和报告软件中的错误和缺陷。Selenium、Cucumber、Junit、TestNG和JMeter等自动测试工具则用于管理、执行和度量功能测试等。

最后总结一下，如果在开发团队和运营团队中间还阻隔了一层人员，那么你就不能无缝执行持续集成和持续交付，也就不能进行DevOps。因此，要想正确的运行DevOps操作，则根本不能拥有（传统型的）QA团队。

QA的未来

那么对于QA工作者来说他们之后会怎么样呢？作为曾经美国最最幸福的工作之一的QA，随着越来越多的组织使用DevOps，传统型的QA工作者们的位置会变得越来越冗余。

根据美国劳工统计局（BLS）的报告，软件质量工程师是高新技术职业中增长速度预计将比平均水平慢的职业之一：

然而，美国劳工统计局的统计数字可能太泛化了因此劳工局还没有将DevOps认定为一个独立的职业：

作为证据，仅仅看一下Google趋势中搜索数据的相对数量就会发现“sqa jobs”的搜索数量正在缓慢下降然而“devops jobs”的搜索数量则在迅速增长：

很明显，QA的趋势看起来绝对不算好。⊙﹏⊙!（ASAF YIGAL原创）