从尝试定义测试开始听上去不错,至少可以作为起点。但是,测试通常听上去更像笔头工作,是一个低价值的角色,很可能被外包。这里,我会分享一些掌控软件测试事业的方式。现在是管理层将测试看为能够增加更多价值的角色的时候了,测试人员也应该能够造成更大的影响力。
测试人员到底做什么?
几年前,在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中国
作者
Matt Heusser is the principal consultant at Excelon Development, where he recruits, trains and does software testing and development.
相关推荐
-
面对软件测试未来的变化
不幸,如今很多软件测试职位都 处于两难的境地。在更快开发并且发布应用的巨大压力之下,企业都会促使测试人员更新他们的技能。
-
新技术给软件测试带来挑战
在软件质量领域,什么才是最重要的技术?软件质量领域专家Gerie Owen谈论了三个重要技术。
-
都是匿名反馈给员工和经理惹的祸
负面的、匿名的反馈都给测试人员和项目经理推进了困境中。测试人员很难对模糊的抱怨做出具体行动,而对于经理来说,提供一些必要的声明也很奇怪。
-
企业软件测试的关键是集中化测试?
在采用敏捷方法论的公司中,企业软件测试中是否存有集中化测试团队的位置,集中化测试对于企业软件测试有什么意义?