找回密码
 立即注册
查看: 17|回复: 0

从瀑布流到敏捷和DevOps,测试该如何改变

[复制链接]

549

主题

549

帖子

1917

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
1917
发表于 2017-12-5 13:58:54 | 显示全部楼层 |阅读模式

          
Laurent Py在Hiptest上发表了博客《向左走向右走:测试的摇摆》,其中描述了当研发模式从瀑布流到敏捷到随后的DevOps,会如何影响测试。在敏捷测试日2015(Agile Testing Days 2015),他以此做了演讲。
InfoQ采访了Laurent Py,了解他们转型到敏捷和DevOps的原因和从“测试摇摆”获取的益处;在测试自动化策略和实施方便,如何通过度量行为改变,来找出一个特性是否是有价值的;以及他预计测试将会带来的特性。
InfoQ:在博客中,你探索了当研发模式从瀑布流到敏捷和现在的DevOps对于测试的改变。你能详细描述下为什么会做出这样的改变?
Py:这主要因为反馈的速度和精益启动的实践。10年前我的团队使用Java和Eclipse进行产品开发。我们每年做两次发布。这个流程的问题是反馈速度。在几个月里,我们开发和创建一个“资产”。但是由于它还没有交付到用户手上,这个资产的价值为0。从商业角度来说,当每年只有2次机会,我们很难快速适应和转变。
因此,最初我们采用了敏捷,同时简化了流程。从工程师角度来看,这是非常有益的,因为我们每两周会出一个工作产品。但是由于这些产品无法立即部署到生产环境,我们同样有反馈速度的问题。用户不会希望没两周就安装一个发布版本。
现在,团队在云上开发新的产品,一个为敏捷团队使用的测试管理平台(hiptest.net)。开发和运维协同工作,并且开始持续部署。由此,我们不仅有了优秀的工程流程,而且最终我们能够从用户获取反馈并且实时做出响应。对我来说,这就是实施敏捷和DevOps而获得的最大收益。
InfoQ:你从敏捷和DevOps中得到了什么收益?
Py:开发出产品是其一;将产品交付给用户是另一方面。因此获取快速反馈的能力,确实提高了团队的参与度。作为一个团队成员,我们能够看见所做功能的影响,并且不用再像以前那样,需要花费几个月才能得到结果。从工程角度来讲,这是非常困难的,并且需要许多训练,但这显然是值得努力的。我相信最终只有一个结局:用户和客户。介于二者之前的其他结果都不能算是成功。
InfoQ:你能解释下你所说的“测试摇摆”的含义吗?
Py:“测试摇摆”我主要想表示向左走和向右走。以前,测试基本上都在开发阶段之后和产品上线之前完成。目前,部分测试活动已经向左移:测试在开发阶段之前设计。这就是行为驱动开发(Behavior Driven Development,BDD)的实践。这能够使得团队成员对他们的最终产品的定义理解相同。所有利益相关方(测试、开发、产品负责人、市场)协作于:
  产品验收标准:样本
  商业验收标准:待验证的假设
然后,我们需要向右走:测试(A/B测试)和直接在产品中监控。重要的是,我们有一个实时用户反馈(通过实时聊天),以获取以前可能无法获取的问题。有的时候,错误的行为可能不是源于代码的错误,而仅仅是一个坏的用户体验或者数据达到一定量的时候才会出现。由于我们有快速的反馈,并且拥有持续部署的能力,我们能够在出现问题的时候快速反应。
InfoQ:在博客中,你提到了你在通过度量用户行为的改变,来判断一个新功能对于用户是否是有价值的。对此能否给一些示例,说明你是如何做到的?
Py:我们在Hiptest中加入了测试重构功能。这是一个关键的区分点,我们可以度量有多少用户真的使用了这项功能。但是度量影响是更重要的。我们已经度量到了,使用这个新功能的用户,增强了自动化水平,同时增加了Hiptest的使用度。因此,当开发一个新功能,并且度量它的价值,不仅仅是询问“是否有用户在使用?”,而是关于对我们商业上的影响和对用户工作流程的影响。
InfoQ:对于测试自动化,你的策略和实践是怎么样的?
Py:每个测试用例都应该讲一个关于应用程序的故事。当一个测试用例使用一致的业务术语定义(行为驱动开发实践),它的可读性会比较高,且容易自动化。这也是Hiptest支持的哲学。顺便说一下,我们使用Hiptest来测试Hiptest,并且使用我们的测试脚本实现100%的自动化。自动化部分通过图形用户界面实现,余下的直接使用API。当然,自动化测试用例和持续集成结合。再次强调反馈速度对于开发者来说是非常关键的。当开发者提交代码时,他需要快速知道这些代码是否破坏了什么东西。
InfoQ:你期望未来测试领域会给我带来什么?
  
Py:我希望测试会更加面向商业。一些人担心质量保证岗位会消失。我认为这是一个机会——如果能把握住的话。如果一个功能没有使用,或者没有给产品带来显著的价值,在功能正确性和性能上投入大量精力又有什么意思?这是测试人员的批判性思维能够发挥作用的时候。为什么我们要构建这个产品?我们构建这个产品的假设是什么?如果答案是肯定的,那么确保正确性才有意义。
查看英文原文:How Testing Changed When Moving from Waterfall to Agile and DevOps
感谢张龙对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群)。

        
       




   
   























   
        
   
   
        
            
        
        
            
        
   




   

   

   
   


        
                        
        




        

        
        
        
        
        

















        

        
        
               
        








   
   

   

   
   
        
         by  
        

        

        
        

        

   
   
   
   
   
   
   
   
       

回复

使用道具 举报

Archiver|手机版|小黑屋|澳门现金博彩  

GMT+8, 2017-12-17 04:50 , Processed in 0.249263 second(s), 20 queries .

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表