来QQ群 :257887726
讨论测试技术的真谛吧

DevOps会导致测试人员失业,何去何从(上)

适合采用DevOps的企业,传统意义的软件测试人员可以消失吗? 这完全是有可能的。Google、微软和一些欧美公司等的实践证明这是可行的。他们去掉了专职测试人员, 没有“TestEngineer”角色,而是采用“测试开发工程师
登录 后即可查看全部文章

DEVOPS 是什么鬼

DevOps可以看做是敏捷开发模式的延伸,将持续集成(CI)、持续部署、持续交付(CD)扩展到运维,打通开发与运维之前的壁垒,在整个生命周期中消除传统的孤岛,促进研发与运维的协作,从而缩短软件产品交付周期,提高软件服务质量。


DevOps强调构建、测试、部署和运维等工作的高度自动化,构建工具链或自动化全覆盖的持续研发的方法和工具,让基础设施、运维也成为产品代码的一部分,能够实现持续设计、持续编程、持续构建、持续测试、持续发布、持续部署、持续监控(持续-X / C-X实践)等,能够及早发现并更快修复缺陷,整个研发更具透明性、运维环境更加稳定,实现越来越快的软件交付,减少协作、测试和沟通成本。 


这里给出一组数据,不管你信不信:相对低性能的同行,高性能的IT组织遇到的失效减少为60分之一,失败后恢复的速度提高到168倍、部署频率提高到30多倍、从研发周期缩短为原来的200分之一。attachments-2018-03-oti1UJLJ5aa11687eba30.pngattachments-2018-03-5hQcFlpN5aa11699a05bf.png



   随着DevOps实践的兴起,测试需求正在下降。这个观点的支撑是:自动化方法已经足够先进,在整个研发、发布和运维过程中在很大程度上人为干预可以逐步减少,先进的、高度自动化的技术解决方案的速度和效率胜过了传统的、基于流程改进的QA/测试方法。

   与之相反的观点,认为DevOps只是一个概念,上述想法只是理论上一种理想,难以落地实施。许多互联网企业由于能力和资源等限制做不了自动化全覆盖,而且工具发现缺陷的能力比较弱,即使能发现60~80%的缺陷,还有20~40%的缺陷会遗留到上线后,这样的质量对大多数应用(更不要说像银行、电信等关键系统)根本不能接受。其次,如果需求定义不规范、不可测或者需求不稳定,自动化测试就很难,还有诸如UI、移动体验之类的组件呈现出许多不可控或不确定的因素,这对于自动化测试来说更具挑战性,而人类测试者却很容易地完成这类测试(UI测试和易用性测试),自动化的代价反而大得多。再者,DevOps只能适用于SaaS(Software asa Service, 软件即服务)这类软件的研发与运维,非SaaS的软件研发很难采用。不同类型的产品、不同的用户和不同的研发团队,采用的软件开发模式和实践千差万别,DevOps在许多场合是不适用的,而适合自己的开发模式和实践才是最好的。

   但是如果公司(如非关键系统的SaaS公司)采用了DevOps模式,有没有可能彻底消灭传统意义的软件测试专职人员?

         如果能,软件研发是怎样的一道风景?

       如果不能,软件测试或QA的地位是不是会下降?

    DevOps这个名字绕过了“测试”,也许是对的,更强调“质量是构建的”。但做测试、做QA的人们一定会有意见,希望将DevOps改为DevQAOps,以纠正DevOps忽视QA的问题,有没有这个必要?甚至有没有必要增加一个新术语TestOps?可能都没有必要,彻底的DevOps也许是未来研发的趋势。


1.  适合采用DevOps的企业,传统意义的软件测试人员可以消失吗?

这完全是有可能的。Google、微软和一些欧美公司等的实践证明这是可行的。他们去掉了专职测试人员,

没有“TestEngineer”角色,而是采用“测试开发工程师 

  • 发表于 2018-03-08 18:56
  • 阅读 ( 650 )
  • 分类:Devops


你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论

如需发布职位,请登录

DevOps会导致测试人员失业,何去何从(上)

适合采用DevOps的企业,传统意义的软件测试人员可以消失吗? 这完全是有可能的。Google、微软和一些欧美公司等的实践证明这是可行的。他们去掉了专职测试人员, 没有“TestEngineer”角色,而是采用“测试开发工程师
登录 后即可查看全部文章

DEVOPS 是什么鬼

DevOps可以看做是敏捷开发模式的延伸,将持续集成(CI)、持续部署、持续交付(CD)扩展到运维,打通开发与运维之前的壁垒,在整个生命周期中消除传统的孤岛,促进研发与运维的协作,从而缩短软件产品交付周期,提高软件服务质量。


DevOps强调构建、测试、部署和运维等工作的高度自动化,构建工具链或自动化全覆盖的持续研发的方法和工具,让基础设施、运维也成为产品代码的一部分,能够实现持续设计、持续编程、持续构建、持续测试、持续发布、持续部署、持续监控(持续-X / C-X实践)等,能够及早发现并更快修复缺陷,整个研发更具透明性、运维环境更加稳定,实现越来越快的软件交付,减少协作、测试和沟通成本。 


这里给出一组数据,不管你信不信:相对低性能的同行,高性能的IT组织遇到的失效减少为60分之一,失败后恢复的速度提高到168倍、部署频率提高到30多倍、从研发周期缩短为原来的200分之一。attachments-2018-03-oti1UJLJ5aa11687eba30.pngattachments-2018-03-5hQcFlpN5aa11699a05bf.png



   随着DevOps实践的兴起,测试需求正在下降。这个观点的支撑是:自动化方法已经足够先进,在整个研发、发布和运维过程中在很大程度上人为干预可以逐步减少,先进的、高度自动化的技术解决方案的速度和效率胜过了传统的、基于流程改进的QA/测试方法。

   与之相反的观点,认为DevOps只是一个概念,上述想法只是理论上一种理想,难以落地实施。许多互联网企业由于能力和资源等限制做不了自动化全覆盖,而且工具发现缺陷的能力比较弱,即使能发现60~80%的缺陷,还有20~40%的缺陷会遗留到上线后,这样的质量对大多数应用(更不要说像银行、电信等关键系统)根本不能接受。其次,如果需求定义不规范、不可测或者需求不稳定,自动化测试就很难,还有诸如UI、移动体验之类的组件呈现出许多不可控或不确定的因素,这对于自动化测试来说更具挑战性,而人类测试者却很容易地完成这类测试(UI测试和易用性测试),自动化的代价反而大得多。再者,DevOps只能适用于SaaS(Software asa Service, 软件即服务)这类软件的研发与运维,非SaaS的软件研发很难采用。不同类型的产品、不同的用户和不同的研发团队,采用的软件开发模式和实践千差万别,DevOps在许多场合是不适用的,而适合自己的开发模式和实践才是最好的。

   但是如果公司(如非关键系统的SaaS公司)采用了DevOps模式,有没有可能彻底消灭传统意义的软件测试专职人员?

         如果能,软件研发是怎样的一道风景?

       如果不能,软件测试或QA的地位是不是会下降?

    DevOps这个名字绕过了“测试”,也许是对的,更强调“质量是构建的”。但做测试、做QA的人们一定会有意见,希望将DevOps改为DevQAOps,以纠正DevOps忽视QA的问题,有没有这个必要?甚至有没有必要增加一个新术语TestOps?可能都没有必要,彻底的DevOps也许是未来研发的趋势。


1.  适合采用DevOps的企业,传统意义的软件测试人员可以消失吗?

这完全是有可能的。Google、微软和一些欧美公司等的实践证明这是可行的。他们去掉了专职测试人员,

没有“TestEngineer”角色,而是采用“测试开发工程师 

  • 发表于 2018-03-08 18:56
  • 阅读 ( 650 )
  • 分类:Devops


你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论
咨询电话:4008-779-565
CopyRights 上海鲁德企业咨询管理有限公司