如何有效地与开发人员一起工作

发表于:2007-11-05 12:05

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:译者:陈能技    来源:51Testing投稿

        开发人员与测试人员通常不能很有效地工作在一起。开发人员能改变,我们也能改变,大家都能改变。我未能幸运地直接改变其他人的行为。但是我能幸运地改变我自己的行为,从而间接地改进开发人员的行为。而他们的改变又给了我很好的反馈,从而建立起一个有效的循环关系。本文是关于我怎样有效地跟开发人员一起工作的方法介绍。 
        我希望我的读者,是那些花大部分的时间寻找bug,跟开发人员讨论,以及写bug报告的测试人员。 
        本文介绍我这些年来学到的三个能把事情做得更好的方法。 
        定义自己的角色,让开发人员觉得他们需要我在旁边帮助他们。我帮助开发人员在bug还没出现之前就把它消除掉,从而减少项目总体成本。 
        给感到疑惑的开发人员解释我的工作。减少对我做出武断的评价和看法的机会,我会使用与众不同的方法来让我的开发人员相信:bug报告不应该被看作是威胁。 
        尽量减少会产生误会和曲解的bug报告 
        这三部分很大程度上是独立的,方法和手段不互相依赖。

  1. 选择一个有效的角色

        在这一节,我首先描述一下我喜欢的角色和这个角色的日常工作。然后描述这个角色解决的问题,最重要的是,可能产生的新问题。 
        假设你被告知要测试某个开发人员的工作,也许是增加了一个新特性到产品中。你也许要同时测试多个开发人员的程序,但是我会在后面的章节覆盖这些复杂的情况。我假设你会在编码阶段开始工作:在开发人员开始写第一行代码后,但在它被完成之前(除了修改bug的情况外)。如果你在更早的阶段介入,那会更好,但是我不假设那种情况。如果你在代码完成后才开始进入你的工作,那么这个章节的作用除了帮助说服你承认下次应该早点介入外,就作用不大了。它也不能应用在那些你不会去找一个开发人员的工作的bug的地方,例如配置测试、压力测试或其它类型的测试。 
        测试组是为谁服务的?一个普遍的回答是“顾客”。在这种模型下,测试人员站在顾客那边,为顾客服务,保护顾客的利益。顾客是一个无助的少女,被绑在铁轨上,一辆失控的火车(处于失控状态的产品开发)冲向她。只有测试人员才能救她,阻止火车(阻止产品发布 - 至少要到bug都修改完)。 
        这个模型有很多问题,不仅仅是这个模型几乎是不工作、不生效的。火车往往冲向少女,让她的救世主失落,士气低下、愤世嫉俗、工作效率低下[Marick97a]。然而对于这篇文章的目的而言,有一个问题是非常相关的:把人们想象成坏人的角色,对于想寻求他们帮助来说不是一个好的开端。不要误会:你其实是要花很多时间从开发人员那里寻求帮助的。你需要他们解释程序,这其实是在要求开发人员给你最宝贵的礼物:时间。你会登记bug并且希望开发人员聪明地处理它们,而不是寻找各种理由来宣布某个bug是一个特征而已,要求有更多的信息,或者干脆开始浪费你的最宝贵的资源:时间。 
        也许我有点夸张。也许没有开发人员会真正相信你在把他们想象成坏人。大概他们会相信某些更糟糕的事情:你把他们看成会频繁出错的人以致不可信赖。大部分开发人员会被认为是坏人而不是缺乏能力的人。但是不管反应的差别有多小,事实是这个模型给了开发人员和测试人员一个不一致的目标。开发人员希望早点发布;测试人员尝试阻止他们。开发人员的合作顶多是一种处于责任感的态度,甚至可能是不满的抵触态度:不可能达到让测试人员融合到项目组中的境界。 
        所以,如果不是为顾客,那么测试组应该为谁服务? 
        我认为应该是为那位对项目的所有事情负责任,并决定产品是否能发布的人而服务。“所有事情”包括了:了解竞争者在做什么;知道程序员因为疲倦而存在的风险,不能进一步提供好的程序,而是提供很糟糕的代码;清楚承诺没有实现带来的代价,产品延期发布给公司和顾客带来的损失。(见[Bach97],会有更详细的讨论。)我把那个人叫做“项目经理”。测试组的工作是为项目经理提供其中一项精确的评估:产品的缺陷率(这个产品的bug多不多),主要是从顾客可能看到并关注的角度去看。(关于这个论点的细节,参见[Marick98a]。关于测试组如何报告缺陷数据和其它类型的需要跟踪的信息,参见[Marick97b]。) 
        让我强调一点,测试人员仍然做的是相同的核心工作产品:bug报告。只是这些bug报告的使用方式不同。不是作为针对和指责产品的证据,而是作为提供给项目经理的信息,以便他做出更好的决定。 
        现在应该很清晰了,这个新的角色定位帮助你跟开发人员一起合作。从他们的角度看看:测试人员就在身边,不断尝试找出可能存在的问题,时刻准备着扑向bug并把它交给项目经理。当然没有人喜欢告密者或搬弄是非的人。 
        那么如何克服这些问题呢?一个解决办法是一个叫egoless programming(无私编程)的项目组结构[Weinberg71],在这种团队里程序员不认为代码是他们自己的扩展,他们不自私,所以他们自己的错误对于他们来说没有那么多的威胁。然而,我不赞成这种方法,因为这意味着开发人员需要改变他们的行为,而不是我要改变。跟我一起工作的开发人员很少有无私的,但是我没有其它的选择,只能跟他们一起工作,接受这个现实的局限性。 
        我的解决办法是转移到private bugs(私有缺陷)和public bugs(公有缺陷)的差异上。私有缺陷是程序员产生的bug,但在把代码签入到公共源代码库之前修正了,它可能会对他的程序员同伴们造成潜在的危害,或者对后面的顾客造成影响。但是一旦bug已经出现,为了保护同伴,要求它必须被公开。(注意这个重要的区别:它不是为了处罚某个制造这个bug的人而公布,而是为了保护其他同伴。) 
        我作为一名测试人员给这些开发人员带来的信息是:我是来帮助他们把bug阻止在private阶段,防止他们出现在public阶段。转眼间,我变成了他们的盟友,成为专注于帮助他们变得更好的人。我的工作就是像他们的一张完全网一样地服务,专注于那些他们不能避免或自己找出来的bug。我是一个工具,作为开发人员的扩展(不要忘记,即使我们与开发人员紧密地工作在一起,他们其实通常都会自己找到更多的bug,比我们找到的要多。) 
        让我澄清一些东西。假设我的开发人员准备好了一块新的代码并且修复了3个bug。我会马上开始测试。唯一会使我推迟测试的是我已经在为另外一个开发人员在做相同的事情。 
        当我找到一个问题的时候,我会发Email给他。我通常不会把那些bug登记到公共的bug跟踪数据库中。我不会把它们跟其他测试员、其他开发人员、项目经理一起分享。它们是私有的。我用自己的Email目录记录并跟踪它们,除非开发人员要求我把它们公开地跟踪起来。 
        开发人员可能不能在把代码放到公共源代码库之前修改所有bug。我一般不同意这种决定,但是我接受开发人员的决定。(这跟我的关于测试组与项目经理的关系的观点是一致的。)如果他不修改bug,则我会把它从Email目录移到bug跟踪系统。因为现在这个bug是公开的,公众(项目经理、其它开发人员)需要知道它的存在。 
        我如果不是在找私有的bug,就是在找公开的bug。也就是说,我完成了测试的代码已经放到公共源代码库了。(也许它已经放到上面了,但是我没能及早分配到这个测试任务。或者是程序员需要让某些内容独立工作,出于演示demo的需要或出于让其它程序员的工作能正常进行的目的。)我在那里找到的bug是公开的并且会报告到公共的bug跟踪系统中去。 
        这样说有点过于简单化了,目的是想说明我的观点:帮助程序员寻找私有的bug。在现实中,事情会更加复杂点。假设刚刚完成的代码不是非常重要,但是代码中的bug已经是public的可能对其他程序员造成严重的阻碍。那么我可能会专注于public的bug。我总能得到开发人员的支持,原因在下个大章节解释。有时候,在项目结束之前,我需要确保所有代码都得到了充分的测试。稳定的变更的测试也不能阻止我这样做。

版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流,如果有任何有关内容方面的合作事宜,请联系我们

51/512345>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号