Linux 之父出席、干货分享、圆桌讨论,精彩尽在 OpenCloudOS 社区开放日,报名戳 了解详情
写点什么

QA 的未来

  • 2016 年 11 月 27 日
  • 本文字数:2209 字

    阅读完需:约 7 分钟

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

2016 年 11 月 27 日 18:001383

评论

发布
暂无评论
发现更多内容

架构师训练营 -week4 命题作业

J.Smile

极客大学架构师训练营

Go:gsignal,信号大师

陈思敏捷

signal gsignal os.Signal Go 语言

消息队列(一)为什么要使用消息队列?

奈何花开

Java MQ 消息队列

架构师面试题(3)

满山李子

架构师培训营第四周总结

王锟

【源码系列】Spring Cloud Eureka

Alex🐒

源码 Spring Cloud Eureka

阿里巴巴的发展史(组织变革+技术变革)

王锟

阿里巴巴

轻松上手promise原理(2):then的简单实现

前端小帅

互联网架构作业

qihuajun

第四周作业

andy

分布式系统设计 - 第四周作业

孙志平

架构师课程第四周 作业

杉松壁

架构师训练营 - 第四课作业 -20200701- 架构演化

👑👑merlan

极客大学架构师训练营

ARTS|Week 5 有效的括号、API和地图

Puran

LeetCode ARTS 打卡计划

极客时间 - 架构师培训 - 4 期作业

Damon

LeetCode | 6. Valid Parentheses 有效的括号

Puran

算法 LeetCode

架构第四周 - 学习总结

J.Smile

极客大学架构师训练营

架构师训练营 - 第 4 课总结 -20200627- 互联网架构设计

👑👑merlan

架构设计 互联网架构

使用数据卷管理数据 | Docker 系列

AlwaysBeta

Docker 容器 数据

架构师训练营 - 第四周 - 学习总结

stardust20

【week04】作业

chengjing

互联网架构学习总结

qihuajun

第4周总结

andy

Week4 学习总结

wyzwlj

极客大学架构师训练营

大型互联网公司技术方案与手段浅析

俊俊哥

分布式 高可用 大型软件 高并发 解决方案

典型的大型互联网应用系统

Z冰红茶

一文搞懂 Redis高性能之IO多路复用

架构精进之路

redis io 多路复用 高性能

通过Python来获取北京市乡镇、街道行政区划数据

Puran

Python GIS geopandas QGIS 天地图

架构师训练营 -- 第四周作业

stardust20

每周学习总结 - 架构师培训 4 期

Damon

消息队列(二)如何保证消息队列的高可用?

奈何花开

Java MQ 消息队列

GPU容器虚拟化:用户态和内核态的技术和实践详解

GPU容器虚拟化:用户态和内核态的技术和实践详解

QA的未来_语言 & 开发_Rui Miguel Ferreira_InfoQ精选文章