技术控

    今日:104| 主题:49431
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] QA的未来

[复制链接]
女人能输不能哭 发表于 2016-11-28 07:49:35
11 0

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
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
友荐云推荐




上一篇:Java EE即将死去,毫无疑问!
下一篇:literate-readme - a readme that is also a literate haskell program!
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表