测试架构师修炼之道:从测试工程师到测试架构师(第2版)
上QQ阅读APP看书,第一时间看更新

1.3.3 从质量守护者到产品赋能者

敏捷开发给测试带来的是挑战,更是机遇。

VUCA

VUCA即易变(Volatility)、不定(Uncertainty)、复杂(Complexity)和模糊(Ambiguity),中文音译为乌卡。2010年,宝洁的CEO Robert McDonald用VUCA来描述当下新的商业格局。

不管我们是否承认,当下我们已经进入了VUCA时代。和工业时代重视专业化分工不同,VUCA时代复杂多变,模糊不确定,没有固定的套路可言,需要我们能够跳出局部,通过系统性思考综合各领域的知识来解决问题,这符合敏捷开发的理念,也符合敏捷开发模式下对测试的定义:专业、综合、适应变化。

尽管Savoia提出了耸人听闻的“测试已死”的论调,但Savoia也在演讲的后面提及:“真正死去的,是那些传统模式下重复的、低效的、堆人的测试,取而代之的是那些更加专业的测试,这些测试不仅不会死,还会成为抢手资源。”

那些烦琐的接口测试,基本的功能验证,都可以用自动化测试来完成。即便是自动化脚本,测试人员也没有必要每一个都去亲力亲为。测试人员可以做好自动化测试策略,搭建好自动化测试框架,和开发人员沟通好测试目标并一起构建好自动化测试分层,这样就建立了自动化的质量防护网。这样测试人员就有更多的精力去做专业性更强、更有价值的测试,比如:

·场景测试,聚焦如何模拟用户的实际使用场景,如何还原用户的操作,紧扣用户的关注点来进行测试。

·性能测试,聚焦如何测出系统的短板和瓶颈,如何确保系统性能满足用户的真实使用场景。

·更高效的探索式测试。

·更有效的测试策略,从根本上提升测试效率和质量。

……

很难想象具备这些能力的测试人员在团队里会不火。

和开发相比,测试更具有系统和全局的视角。这和工作场景息息相关。瀑布开发模式下,系统被细分为足够小的模块,然后由开发人员实现,这种割裂式的工作模式让开发容易陷入“只见树木不见森林”的状态。即便是敏捷开发模式下,我们可以使用“用户故事地图”等满足可视化需求,让团队可以看到需求全貌,但是工作内容还会导致开发人员容易陷入实现细节中。现实中,无论是瀑布开发模式还是敏捷开发模式,不知道用户会如何用这些功能的,不知道为什么要做这些功能的开发工程师比比皆是。

相比而言,测试人员比开发人员更具有“大局观”。测试人员不容易陷入实现细节中,更关注用户的使用,关注用户显性和隐性的需求,更具备全局性系统思考的条件。遇到问题后,测试人员比开发人员更容易跳出局部,看到问题的根本原因,从而更有效地解决问题。这种能力在VUCA时代变得更加重要。

VUCA时代具有的混沌不定性,导致即便是用户提的需求,可能用户自己也没有完全想明白,对于同一个功能不同的用户可能会有截然相反的意见。这使得在产品开发中很多设计都没有标准答案,“测试预言”(判断测试是否通过的标准)往往成了解决问题的关键。一个专业的测试人员可以基于“对行业的理解”“对用户行为的剖析”“对使用场景的分析”“对友商和竞争对手的了解”等对测试是否通过做出判断,其就像一位优秀的法官,可以明辨是非。正因为如此,很多企业会让测试人员去做产品研发的接口人,和一线售前人员一起做方案、和用户沟通、处理售后问题等,这看起来虽然有点“不务正业”,但是从企业经营的角度来说,是帮组织解决了大问题,这些工作更容易被管理者看到,进而获得新的发展机会。

敏捷开发模式的开放性使得团队中的测试人员只要有想法、有能力,就可以做任何有利于用户或团队的事情,而不用担心测试的身份。这使得测试人员有机会“轮岗”,了解别的职位,找到更适合自己的发展方向。除此之外,测试人员对产品和系统理解的“宽度”,也为测试人员转行奠定了良好的基础:一名测试工程师如果想转行,那么他无论转行做售前、售后、销售、产品、支持等,做测试时打下的那些对产品功能全面深入理解的基础,都可以帮助他快速上手,在新的领域赢得认可。这也让测试人员在VUCA时代更具有竞争力——能够有更多的选择适应变化,这本身就是一种能力。

在瀑布开发模式横行的时代,我们希望测试人员是质量守护者,是产品质量的最后一道防线,尽管组织对测试人员寄予厚望,但结果往往不能令人满意。敏捷开发模式下,那个“守护者”慢慢死掉了,涅槃重生的是更加专业的测试人员,他们是具有更多综合能力的测试人员,具有更强的适应性,可以有更多选择。他们把测试的独特视角带入各个岗位角色中,在跨界中碰撞出新的火花,赢得认可和尊重,成为产品的赋能者。