BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Ben Linders 关注 20 他的粉丝 ,译者 金灵杰 关注 5 他的粉丝 发布于 2015年11月18日. 估计阅读时间: 6 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT