2016年管理好软件测试事业

日期:2016-1-21作者:Matt Heusser翻译:崔婧雯来源:TechTarget中国 英文

【TechTarget中国原创】

从尝试定义测试开始听上去不错,至少可以作为起点。但是,测试通常听上去更像笔头工作,是一个低价值的角色,很可能被外包。这里,我会分享一些掌控软件测试事业的方式。现在是管理层将测试看为能够增加更多价值的角色的时候了,测试人员也应该能够造成更大的影响力。

测试人员到底做什么?

几年前,在SearchSoftwareQuality里,我发表了一篇文章,关于回答“为什么QA一直是瓶颈所在”这个问题。这篇文章对这个问题可能是不公平的,但是它本来也不需要公平。Tim Lister,我崇拜的一个人,在Better Software大会上的主题演讲里提出,软件测试人员的工作就是只发布好的东西;而将其他不好的东西打回去。也就是说,当测试人员终止某个工作流时,他们只不过在尽职工作而已。

这是有关测试,或者质量保证(QA)的老看法,确保错误不会暴露给用户。这样的定义设置了与开发人员的对抗,开发人员想发布新代码,而测试人员,希望确保代码正确。但是这样的看法并不是唯一的。软件测试的上下文驱动的想法倾向于建议测试能够向决策制定者通知软件状态。也就是说,测试人员执行分析,包括可操作的细节,但是随后让管理层来决定怎么处理软件。随着交付越来越快,我发现一些领导并没有时间或者兴趣,来帮助决定哪个bug必须修复。我的目标变成了了解他们,以及他们是怎么想的,从而我们可以做出产品所有者可能会作出的决定。这样,测试人员成为初级产品所有者,拥有一些产品和特性的权利。这不是“给高级管理层的信任公告”,它意味着测试人员能够不受阻碍地更大地影响发布团队。

一些公司的软件测试职业发展道路上有“测试架构师”的角色,但以我个人的经验,这个角色实际非常困惑。我的朋友Noah Sussman,建议使用另一个角色:QA架构师。

QA架构师成长之路

人们通常认为测试和质量都是为了预防错误发生。产品发布前,我们要确保软件足够好。这让IT花费了很多时间思考如何部署、什么时候部署、改变控制,等等。如果测试人员会因为错误而受罚,他们就会努力工作尽量避免错误,从而会减慢整个系统的速度。假定在一个游戏里,你将很多东西堆在平板上,当越堆越高时会崩塌。你的目标是确保没有东西掉到平板外面。那么在放置每一块时你就会很小心,这会降低新特性(块)交付的速度。

另一方面,编程人员,想要拿到平板上越多的块。

Sussman提出,结束这样冲突的解决方法,是让质检角色最小化失败的影响。这种理念的一部分和DevOps重合,包括快速部署到快速回滚,监控生产环境以便快速定位问题,临时环境回滚以及功能标签。

不用完全脱离这些想法,我建议——让软件测试有益于你的事业——我们需要拥抱它们,创造出真正的QA架构师,他负责在快速变化和预期失败之下确保系统的稳定性。可以从历史数据开始:系统多久失败一次,下线时间多长,以及,如果可能的话,多少人受这样失败的影响?

比如,将执行持续交付的团队和使用两周冲刺经典Scrum团队作比较。Scrum团队在新冲刺开始前的周日晚上,将代码交付到生产环境。如果在冲刺一第一周的周一早晨发现bug,那么会将这个bug添加到下个冲刺 backlog里,会在冲刺二里解决,从而在问题发现的四周后部署到生产环境里。

实践持续交付的团队会在发现问题的当天修复问题,这比Scrum团队快20倍。持续交付团队可能会处理10倍bug,但是对客户只会造成一半的影响。

这些数字都是理想场数字,但它们的确和我的实际经验匹配。如果有机会通过关注更快响应问题来改进交付时间,测试人员就能够成为解决方案的一部分。在一些情况下,测试人员甚至能够设计解决方案——这对于软件测试事业肯定是个好消息。比如,我曾经工作过的一家公司,有个技术人员针对生产环境编写自动化的检查。他们并没有做太多事情,只是登入系统,在循环里查看某个特定用户网站,但是他们涵盖了时间数据。当客户开始抱怨尝试登陆超时时,这样的时间数据提供了问题发生时的更为详细的数据,并且精确表示了影响有多坏。

最终分析

能够在测试领域成功的人都擅长于解决无限的问题集,从中分析出几个核心问题,得到合理的结论,并且和各方沟通这样的结果。这样的工作和高级管理层的质量监控工作有所重合。最大的不同在于测试更加接近工作本身;测试人员能够看到项目实际发生的情况,以及在咖啡站大家谈论的内容。高级管理层通常和实际工作没有什么联系,并且依赖于实际完成工作的人员的汇报。这意味着测试能够充当独立监管员的职责——以最可能的方式。

测试人员作为顾问的方式在传统拥有测试阶段的企业里可能工作得更好。在每几周就要交付,甚至更频繁交付的企业里,产品质量和截止日期更为不确定。这时候,你可能需要系统长期稳定性的建议,并且找到衡量和管理方式。无论怎样,关键是要真正负责你自己的流程。找到目前最适合自己和公司的模型,并自定义具体的方法、操作,以及向这个方向前进的想法。

如今很多企业缺乏测试和质量有价值的愿景。这造成了一个真空、空白的区域。不要仅仅告诉大家应该是什么样子,而是要采取行动,看看到底会发生了什么。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Matt Heusser
Matt Heusser

Matt Heusser is the principal consultant at Excelon Development, where he recruits, trains and does software testing and development.

Web服务性能>更多

  • 当web成为选择 开发原生移动app还值得吗?

    随着iPhone的推出,其进入的代价是通过苹果应用商店流通的编译过的Objective-C二进制代码的分发。

  • 顶级APM软件大PK

    管理应用性能说起来容易做起来难。在探索很多种方式,研究很多种趋势之后,应用性能管理能够快速地从简单进化到复杂。对于APM软件而言也是如此。

  • 理解CEP应用真正特点

    IT领域的每个人都知道分析,以及借助大量历史数据作出更优业务决策的价值。这里应用程序的挑战在于“历史”这个限定词。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

相关推荐

  • 面对软件测试未来的变化

    不幸,如今很多软件测试职位都 处于两难的境地。在更快开发并且发布应用的巨大压力之下,企业都会促使测试人员更新他们的技能。

  • 新技术给软件测试带来挑战

    在软件质量领域,什么才是最重要的技术?软件质量领域专家Gerie Owen谈论了三个重要技术。

  • 都是匿名反馈给员工和经理惹的祸

    负面的、匿名的反馈都给测试人员和项目经理推进了困境中。测试人员很难对模糊的抱怨做出具体行动,而对于经理来说,提供一些必要的声明也很奇怪。

  • 企业软件测试的关键是集中化测试?

    在采用敏捷方法论的公司中,企业软件测试中是否存有集中化测试团队的位置,集中化测试对于企业软件测试有什么意义?

技术手册>更多

  • 复杂事件处理CEP手册

    在金融服务和其他行业中,如何使那些重要且具有战略意义的业务信息以高速数据流的方式到达企业变得尤其重要,而复杂事件处理(CEP)就是这一过程的代名词。在复杂事件处理中,数据是不断变化的,而“操作”是“静态”的。复杂事件处理具备了分析高速数据流并鉴别重要事件的能力,虽然对这些事件的鉴别过程是复杂的,但结果却是无价的。复杂事件处理能够帮助企业及时全面地洞察市场变化,降低风险和提高决策效率。下面我们就来介绍一下复杂事件处理。

  • SOA与遗留系统详解手册

    遗留系统是一个已经运行了很长时间的,对机构来说是很重要的系统,但是往往不知道如何处理的大的软件系统。它与平台相关,但不能在网络环境中直接访问。另外,遗留系统不能直接访问存储在各种数据库管理系统中的数据,但由于遗留系统所完成的是关键业务,所以不能简单丢弃。本技术手册提供了一些意见和技巧,仅供参考。

  • 云数据架构快速指南

    新的云数据架构快速指南提供在云数据架构中,您所需要的技巧、专家建议新闻、趋势和已经实施了云数据架构的企业现状是怎样的,下一步他们打算如何做。下面让我们看看详细内容。

  • OSGi模块化技术手册

    最近有一些争论,主要是关于是否完全成熟的OSGi模块化是严格意义上必须的东西,或者Jigsaw是否一种足够好的“更简单”的方法。但是也许关键点在于对于任何既定的组件在哪里适合什么模块化。OSGi是Java领域里无可辩驳的最成熟的模块系统,它与Java几乎是如影相随。在这本技术手册中我们将分三部分来和大家聊聊OSGi模块化以及它和Java千丝万缕的关系。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算