软件测试管理

当前位置:首页 > 软件测试管理

《Google软件测试之道》第五章

第五章 Google软件测试改进


Google的测试流程可以非常简练地概括为:让每个工程师都注重质量。只要大家诚实认真地这么做,质量就会提高。代码质量从一开始就能更好,早期构建版本的质量会更高,集成也不再是必须的,系统测试可以关注于真正面向用户的问题。所有的工程师和项目都能从堆积如山的bug中解脱出来。


如果你所在的公司能对质量达到这种层次的关注,那就只剩下一个问题了——下一步是什么?


其实,Google 的下一步已经开始在进行了。当我们不断完善产品开发中测试角色的时候,我们其实也在流程中引入了几个明显的缺陷。本章就来讲讲这些缺陷,讨论一下为了解决这些问题,Google的测试是如何进化的,抑或是如何退化的。测试的去中心化已经发生了,工程生产力部门(Engineering Productivity) 已经被拆分融入到各个产品团队。我们认为这是达到一定的测试成熟度以后的一种自然结果。在Google继续区分开发与测试已经不是最好的选择了。


5.1 Google流程中的致命缺陷


测试通常被看做是质量的代名词,如果你问一位开发人员做了哪些与质量相关的事,他的回答往往是“测试”。可是测试并不能保证质量。质量是内建的,而不是外加的。因此,保证质量是开发者的任务,这一点毋庸置疑。这就带来了第一个致命的缺陷:测试成了开发的拐杖。我们越不让开发考虑测试的问题,把测试变得越简单,开发就越来越不会去做测试。


在实际生活中有一个类似的例子:我们坐在舒适的沙发里看电视的时候,有人来为我们修剪草坪。而实际上,我们是可以自己修剪草坪的。更糟糕的情况是,当他们在为我们修剪草坪时,我们却坐在家里,什么事儿也没有!修剪草坪的服务让我们很轻松,是太轻松了,以至于想都不想就外包出去了。当测试也成为一种服务, 能让开发想都不想的时候,那他们就会真的什么也不想了。测试应该需要一点痛苦,需要开发人员费点心思。某种程度上我们已经把测试变得太轻松,把开发养得太懒了。


测试在Google作为一个独立的部门,让这个问题更为严重。保证质量不但是别人的问题,它甚至还属于另一个部门。这就像我的草坪服务,责任方很容易确定,出问题的时候也很容易就把责任推卸给修前草坪的外包公司。


第二个致命缺陷,还是与开发和测试的组织结构分离有关。


测试人员更关注自己的角色,而不是他们的产品。如果产品不被关注,那它就好不了。毕竟,软件开发的最终目的不是编码,不是测试,不是文档,而是完成一个产品。每一个工程师的角色都是为总体产品服务的,而角色本身是次要的。健康的组织的一个标志是,人们会说“我在为Chrome工作”,而不是“我是测试”。


几年前,我在一次测试会议上看到一件T恤用希腊语和英语写着“我测试,故我在”。这件T恤的制作者一定觉它无比巧妙,但我认为这不过是一种好斗的口号,不利于整体产品一它过分强调了测试角色的作用。任何角色都不应被过分强调。团队的每个人都是在为产品工作,而不是为了开发过程中的某个部分。开发过程本身就是为产品服务的。除了做出更好的产品,流程的存在还有其他目的吗?用户爱上的是产品,而不是开发产品的流程。


在Google,开发与测试的分离造成了基于角色的关联,阻碍了测试人员对产品的关注。


第三个致命的缺陷,是测试人员往往崇拜测试产物(test artifact)胜过软件本身。


测试的价值是在于测试的动作,而不是测试产物。


相对于被测代码来说,测试工程师生成的测试产物都是次要的:测试用例是次要的;测试计划是次要的; bug报告是次要的。这些产物都需要通过测试活动才能体现价值。不幸的是,我们过分称赞这些产物(比如在年度评估时,统计测试工程师提交的bug数目),而忘记了被测的软件。所有测试产物的价值,在于它们对代码的影响,进而通过产品来体现。


独立的测试团队,倾向于把重点放在建设和维护测试产物上。如果把测试的目标定位在产品的源码上,整个产品都将受益。因此,测试人员必须把产品放在第一位。


最后一个致命缺陷也许是最深刻的。产品经过最严格的测试发布以后,用户有多大可能仍然发现测试中遗漏的问题?答案是:几乎必然发现。我们谁都没见过哪个产品能够避免漏测问题所带来的困扰(无论在Google还是其他地方)。创作本书时,我们三个作者都在为Google+这个产品工作。事实上,许多Google+中最好的bug的发现者是Google的内部试用者(dogfooder)——那些 Google+团队以外试用这个产品的Googler。我们想象自己是用户,而内部试用者就是真实的用户!


是谁在做测试并不重要,关键是进行了测试。


内部试用者、可信赖的测试者、众包测试者,以及早期用户都可能比测试工程师更容易发现bug。实际上,让TE做的测试越少,支持其他人做的测试越多,效果就越好。


有这么多问题,我们能做些什么呢?怎么找出Google测试中所有做的不错的地方,并使其更加专注于产品,更加以整个团队为导向呢?我们正进入一个未知的领域,我们唯一可以做的就是推测。但是我们认为,本书揭示的一些趋势,为推断测试在Google和其他公司的未来发展提供了基础。其实SET和TE的角色本身,已经向着未来的方向转变了。


在Google,其实这两个角色正向着相反的方向发展。SET的角色越来越像开发,而TE的角色向着相反的方向越来越像用户。这种转变就像成熟的软件开发组织的自然进化一样,正在有机地进行。一方面,这种趋势来自于技术革新,软件开发周期更加紧凑,开发、测试和用户可获得一致的持续构建版本,其他相关的非技术人员有机会参与到软件开发过程中。另一方面,也是由于质量保证的观点更加成熟,质量需要每一个人的贡献,而不专属于“测试”工程师。


5.2 SET的未来


简单来说,我们认为SET没有未来。SET就是开发。就这么简单。在Google,SET的薪资与开发一样,以开发的标准评估绩效,并且两个角色都被称作软件工程师。如此众多的相似点只能引向一个结论:他们其实就是一个角色。


这个角色正逐步淡化,但其工作本身并不会消失。SET承担的工作在Google相当关键。SET直接负责很多功能特性,如可测试性、可靠性、可调试性,等等。如果我们把这些功能特性与用户界面及其他功能模块一样对待,那么SET就是负责这些功能特性的开发工程师。这就是我们认为SET这个角色在Google和其他成熟软件公司在近期将要发生的演变。除了把测试开发与其他功能开发同等对待,还有什么更好的方法能让它成为“一等公民”呢?!


这正是目前的开发流程里存在问题的部分。面向用户的功能都被产品经理(PM)管理,并由软件开发工程师编写。这些功能的代码,通过一套良好定义的自动化流程跟踪、管理和维护。然而,为什么测试代码却由TE管理,由SET编写?这是测试角色演变过程中遗留下来的。但是这种演变已经到头了,是时候让测试代码成为一等公民了——测试代码也由PM管理,由软件工程师编写。


哪些软件工程师能胜任测试开发工程师,负责质量方面的功能,并恪尽其职呢?像Google这样的公司已经有了软件测试开发工程师(SET)这个角色,只需要让他们转为开发工程师就可以了。但在我们的印象中,这不是最好的解决方案。开发工程师,可以通过负责质量方面的各种功能特性受益(注:Google有一个服务可靠性工程师(SRE)计划,称为质控使命。工程师在完成为期六个月的SRE计划后,可以获得一笔可观的现金奖励和一个镶有“质控使命"Google奖章的皮质夹克)。然而,强迫人们做这件事情是不现实的,也不是Google的方式。测试特性应该由团队的新成员负责,特别是那些资历尚浅的员工。


下面讲讲我们的理由。测试这个功能特性贯穿了整个产品。因此,负责编写测试功能特性的开发者,就必须学习产品从用户界面到API的方方面面。除此之外,还有什么更好的办法迅速学习产品的设计和架构并进行深入研究呢?对任何团队的任何一个开发者来说,全面负责产品的测试功能(无论是从头开发、修改、还是维护)都是一个非常理想的热身项目,或者说其实是最佳的热身项目。团队里来了一个新成员的时候,原有的测试功能开发者就转去负责其他的功能而让位给新成员。每个人都从不熟悉到融入,逐渐所有的开发者都非常理解测试,并真正认真地对待质量。


资历尚浅的开发人员,或是刚从学校毕业的学生,会发现测试开发绝对是最好的起步点。他们不仅能从中学习整个项目,而且由于测试代码不会最终发布,也就避免了产生影响到最终用户的bug带来的压力和尴尬(至少不会在职业发展初期发生)。


这种单一角色的机制与现在Google采用的机制的本质区别是,测试的技能被平均地分散到各个层级的开发工程师身上,而不是集中于测试开发工程师(SET)那里。这个不同非常重要,因为它消除了测试开发工程师这个瓶颈,从而能够带来更高的开发效率。不仅如此,工程师不再有名称上的差异,开发产品的功能点和进行测试开发就不再有相互之间的隔阂和歧视:共同的角色,共同的团队,为了共同的产品而努力。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~