BT

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

QA的未来

| 作者 Rui Miguel Ferreira 关注 2 他的粉丝 ,译者 冬雨 关注 4 他的粉丝 发布于 2016年11月28日. 估计阅读时间: 7 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

Mark Hrynczak是Atlassian的云质保管理者,在本年度公司峰会上做了演讲,共享了他对高价值质保团队的看法。

他是如此定义高价值质保团队的,首先,要与公司战略目标完全一致,从而能在最重要的问题上做出贡献,这些问题是一个组织在特定时刻可能要面对的。

所提出的“质保冠军”的模型,是最近从公司已经沿用过一段时间的“质保”模型演变而来的。这两个模型都依赖于质保和开发团队职责的转变,以及与公司战略目标建立更紧密的联系。

Atlassian对质量有一个宽泛的定义。可以借鉴Gojko Adzic的软件质量的层次结构去找适合你自己的,它与Maslow的需求的层次结构很相似。根据演讲者所说,有一个关于软件及其质量的问题非常好,很值得回答,那就是:“我们怎么知道它是不是有用?”

InfoQ与Hrynczak就演讲中几个主要方面的细节内容进行了讨论。

InfoQ:你能简略向读者们解释一下什么是“质保”的构成吗,它又是如何演变为现在所谓的“质保冠军”的?

Mark Hrynczak:质保是基于软件开发团队需要去优化质量和速度的洞察的,而不是这一个与那一个的权衡。与增加更多测试阶段、更多过程和更多测试人员相反,我们强调和培养开发人员从产品质量标准出发去测试他们自己的特性。与质保团队直接提升软件质量相反,我们的团队目标是去改进开发团队生产软件的质量。我已经就此主题在https://www.atlassian.com/inside-atlassian/qa上写了不少文章

InfoQ:净推荐值(NPS)是公司用于保证战略性的推荐工具之一,他们专注于正确的问题。因为NPS是评估客户对整个公司满意度的工具,你如何建立质保团队成员与之的联系呢?

Hrynczak:我们是基于产品来使用NPS的,通过在线聊天即时请大家对当前使用的产品进行评价,以此方式把数据收集上来。我们的产品有非常大的用户基础,基于这些数据的收集和分析,我们就这些用户对产品的感觉得到大量的洞察力。这些洞察力指导我们做出下一步的决策——用户想要看到什么功能,产品的哪些地方难以使用,哪些类型的缺陷或行为对他们有最严重的影响。我们不打算让具体团队成员的行为与整个NPS得分有非常强的关联,它度量的是整个团队。因为我们是基于从这些收集的数据中得出的洞察力上采取行动的,所以我们应该预期看到与那些洞察力相关的数据子集的上升趋势,具体表现即为更满意的用户和更好的产品。

InfoQ:其中讨论的一个关键思想是提升用事前技术代替事后补救的能力,比如预防、缓解或根除。你能给我们举一些应用案例吗,通过它们能得到怎样的收益?

Hrynczak:当然可以,下面我针对你提到的技术举一些例子:

  • 预防:这是一个注意具有共同原因的缺陷在哪里频繁出现的模式,比如某些特定情况会引发一些不希望的后果。测试人员按传统方式可能会创建一组字符串作为默认的测试数据,每当交给他们软件进行测试时,他们都会用这些字符串去检测缺陷,大家公认这就是成功的测试人员。而如果用预防的方式,我们则会把这些字符串在开发人员编码前就交给他们。我们事前约定这些应该予以支持的特定情况,开发人员编写代码对这些情况予以处理,并用它去进行自动化的检查。
  • 缓解:产品系统有成千上万的用户,如果一个缺陷部署给所有用户会造成不可估量的后果。传统的测试方式会花时间和精力去试图找出每一个潜在的缺陷,防止用户受到影响。如果用缓解的方式,我们可能会改变部署策略,把上线计划错开,蓝色/绿色部署,错误监控和自动回滚,等等。同一个缺陷可以在之前的部署中检查出来,而一旦缺陷暴露出来时,我们停机或回滚只会影响到非常有限的用户。使用好的策略,我们可以把影响范围限制在内部或不重要的用户上,那么实际用户就永远不会看到缺陷并受到它们的影响了。
  • 根除:如果开发人员意识不到(或不注意)而未编写防御代码,就会引发安全性问题,但它只会形成一个导致你的产品不安全的弱点。和针对每次变更执行广泛的安全性测试不同,我们会通过使代码默认安全而大大减少出现这些问题的机会。我们会在模型库中执行自动转译以避免XSS缺陷。我们会要求所有表单自动生成token以避免CSRF缺陷。我们可能无法彻底消除所需执行的安全性测试,但我们能大幅降低类似缺陷的出现。

InfoQ:如果一个组织认为质保环节是瓶颈了,想要向你们学习,你能给他们提些具体建议吗?

Hrynczak:转换传统模型为质保的思维需要组织文化的转变,不仅仅是质保,还有开发人员、领导和其他利益干系人。你可能不需要立即说服每个人,但希望更多的人看到效率和质量目标被实现时会欣赏这种模型。这里有几个先决条件:

  • 管理对这些抱支持和开放的态度。他们必须坚持让整个团队为结果负责,不论结果好与坏。他们必须认识到,开发人员花更多的时间去编码和测试一个故事是通过跳过测试更好更快地完成它。他们必须控制自己的心态,不要保持思维惯性,认为发布出去了严重的缺陷是因为质保团队没有发现它。
  • 开发人员关注最终用户,本质上会促进写出高品质的软件。优秀的开发人员能写出并交付高品质的、零缺陷的代码,并坚信靠测试团队去发现缺陷是不可能满足这一点的,这应该成为一个普遍认知。
  • 质保团队成员能明白他们的价值远在“测试”之上,理解快速开发流程的现实需要,能够抛弃他们是不可靠的开发人员和有价值的最终用户之间的守卫的思想。这些的角色所需的技能是不同的,可能需要你走出你的舒适区。我在 https://www.atlassian.com/inside-atlassian/software-QA-skillsh 上就此有更多的阐述。

点击查看完整的讨论视频。

查看英文原文The Future of QA at Atlassian

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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