开发人员做代码变动需要得到批准

开发人员做代码变动需要得到批准

从理论上来讲，开发和测试是平等的，这个大家也都能接受，只有平等才能进行有效监督嘛。可是，“泥巴怎么捏”的权利在开发人员手里，他在大家都不知情的情况下对代码做改动，你能怎么样找他打-一架p>

在项目后期，不管开发人员出于好意还是出于对技术或者完美性的追求所做的代码变动，实际上都是项目的一个风险。很有可能他的改动中包含错误，也有可能他的改动会对其他模块带来不利影响，他不可能考虑得那么全面，所以，我们需要控制这种改动。从配置管理的角度来说，对变更的控制是项目的一个关键。项目必须在控制之中，而不能被某一个开发人员的“心血来潮”拖入泥潭。

微软这方面做得很好。到了项目后期，每一个代码的变动都需要经过评审小组的批准，没有得到批准而对代码做变动会被公开批评。在一个专业的小组中，被公开批评是一个很大的负面评价。这个评审小组的成员包括开发组长、测试组长、需求组长等人，他们每天开会来决定当前有哪些变动可以被批准。所以，你会看到，开发人员会小心地陈述理由以争取变动获得批准，他们的“随意修改”的权利已经被剥夺了。有的时候，当的确是因为编程.上的错误导致了一个软件错误时，开发人员想修正自己的错误，在争取批准的时候就会比较着急，生怕得不到批准。

这个制度巩固了开发和测试的平等关系，避免了产品质量的动荡，值得学习。

认真考虑用户的真实使用场景

我在项目组内的工作之一就是测试Toast，我是这个功能的Owner（负责人）。当你使用MSN的时候，你的朋友发消息给你，你会在屏幕的右下方看到一个小窗口，这就是Toast。我们的产品虽然不是MSN，但是是类似产品。

Toast虽小，可是我不敢含糊。从Toast的种类、触发条件、·显示内容、UI效果等出发，我编写了多个测试用例。几轮测试下来，自我感觉还不错。

可是在测试后期Beta用户 告的一个问题却让我有些惭愧,这个问题是这样的，的确，每次有联系人登录或者收到次对话的第条消息的时候，用户都希望看到Toast，这样用户能得到明确的提示。但是，从另外-个方面来讲，用户也不希望当前的.L作被中断，例如，如果用户在写邮件，他既希望看到Toast，也希望能够继续写邮件，用户的当前焦点不能变。这就要求Toast显示出来后，既要显示到桌面的最前，又不能抢夺用户的焦点。这个问题的价值很大。它让我看到自己的测试思维有一个盲区:用户的工作环境。这个工.作环境不但包括用户的计算机硬件、操作系统、办公软件、浏览器，还包括工作场景(scenario），就是用户的某一时间段的工作状态。

在测试环境.上，测试总有一个要求:单独的、干净的测试环境。这是没有错的，只有在单独的干净的测试环境中得到结果才有意义。但是，这并不表示我们不需要考虑用户的实际工作环境。从另外-个角度来看，我们还要考虑用户可能在什么场景下使用我们的产品，要设计出这方面的测试用例，以发现可能存在的问题。我们照样可以在测试环境中模拟出用户的办公场景，这与环境的独立性和干净没有冲突。

这样的考虑是不是有点多余你现在的产品并不是商业软件，只卖给一个或者几个特定的用户（为讨论方便，我们称它为项目软件吧〉，或许你会有这样的想法。其实一点都不多余，项目软件的领域中也存在着竞争，项目软件的用户也会越来越挑剔，如果你能够为用户多考虑一点，就能为你的产品博得好的声誉，在竞争者当中脱颖而出。在竞争公司技术水平大体相当的情况下，这种胜出是由类似的多个细节组成的。

Non-goal（非自标)

可能是因为计算机的威力太大了，有的时候它简直就是无所不能，这也给一些客户造成了一个假相，似乎只要他们张嘴，新需求就一定能实现。在国内软件业竞争激烈的背景下，客户可以不管软件开发的实际阶段（可能已经到了最后一个里程碑或者最后几天），不管需求是否符合实际（可能根本用不上），不管软件公司是否能够承受（可能软件公司已经不可能再做软件基本结松的修改了)，对软件提出不可抗拒的修改意见，有的修改意见甚至就好像楼房已经建到10层，来了…个修改地基的需求一样。我知道，即使在湍求规格说明书中增加non-goal，对这种情形也并没有什么作用，但或许对客户有一个心理作用吧，软件产品也只是普通的产品而已，不是橡皮泥，能捏成任何形状。

同事之间的审阅

如何提高代码质量，是·一-个经常被提及的话题。测试是软件质量的一道防线，是不可缺少的，而且是软件开发“三分天下”中的支柱之一。但是，如果能提高软件代码质量，减少bug总量，也就减少了软件的风险。

软件开发因为其工作的特殊性，很难进行管理。我的职位虽然不是开发，但我经常能收到列发人员提交代码的通知邮件，在这类邮件里，我注意到，都有一栏:窜阅者（Reviewer)。也就是说，如果你是-个开发人员，在你向代码服务器提交代码之前，需要找另一位开发人员来做审阅，在取得他（她）的同意的惰况下，才可以提交代码。如果发现了错误或者不完善的地方，斑当立即进行修改，再做审阅。

我觉得这样做的好处有:

(1）增强了开发工作的透明度。
(2〉在具体的开发细节上都体现了多个人的智慧。
(3）这是切实可行的监督方法之一。如果等产品都开发完了，再来审阅几万、十几万行的代码，简直就是不可完成的任务。

我认识一位建筑业的驻地监理工程师，我向他请教了他们是如何做监理的。建筑业的风险也很大，代码有的时候还能推倒重来，建筑是不可能了。他给我举了一个例子，他说，有一次监理一个立交桥，他们的工作仔细到对每一车的混凝土都做检查，并且都要留样。所以，建筑工人工作到什么时候，他们就要工作到什么时候。我想，这种严格的精神也需要在软件业得到承传。

同样，这种同事审阅的制度也可以迁移到测试上。如果一位测试工程师修改了测试工具、测试计划或者测试用例，也需要找另一位测试工程师来做审阅，然后才能提交，我相信这会提高测试工作的质量。

最大的收获-专业精神

可能有人要问我，在微软T.作的这-·段时间里，你最大的收获是什么呢一个很好的问题，我要认真想一想。

我觉得我很幸运，到徼软后就赶上了一个好项目。这个项目在微软来说很小，却是“麻雀虽小，五脏俱全”，其包含了多种软件技术。我从M1就进入到了项日组，一直到最后产品的发布，全程经历了一个完整的也是成熟的软件开发流程，这种项目经验会认:我受益很大。

然而，我仍然觉得，我在微软工作的最人的收获是见到了一种专业精神，并受到了些许熏陶。

微软的工作氛围是很好的，无论是在中国还是美国总部，有很多优秀的员.7:，无声地做出了榜样。从邮件书写，谈话方式和语气，表达自己的观点，到对bug的态度，对变化的应对，对新东西的理解等等，从中都能发现专业之道。大家都是在努力地把事情做好，没有什么杂事搀和在里面。例如，前几天你对一个问题的看法错了，你会发-一个邮什承认自己错了;开会迟到了或者错过了会议，你会主动发邮件告诉大家原因并表示歉意;如果你需要重新启动服务器，之前你要查清现在的确没有人使用它，在发了邮件通知大家后，你才会去重启它，以免对他人的工作造成干扰;偶然遇到 个不是你负责的模块的bug，你会把它告诉相关人员，而不是让它溜掉;在你解释了两遍之后，对方仍然表示没有明白，你不会露出不屑的表情，而是再解释·遍，等等。专业都是在细节中体现，专业精神体现在让事情做得更好的点点滴滴上。

说句大一点的话，见笑了，我希望我们国家能够有越来越多的专业.工程师，这样软件业才有希望。

在微软这样的大企业里，员T.都是很独立的，员.工之间在工.作上的联系，就好像是两个小企业的联系，很正式。只要是为了完成一项任务，没有什么别的考虑，目标就是一个:把事情做好。作为一名员.工.，他（她)的所作所为，一方面是在做工作，同时也是在展现个个体，每个人都想表现的专业和优秀。当他有了这种想法，就会对自己加以控制，向着专业的目标奔去，就好像自己给自己加了发动机，这种情况的产生大概就是近朱者赤吧。

我很难描述这种氛围是什么，大概是-种柔和而催人进取的氛围。我觉得，在这样的氛围中.T.作是一种幸运。更希望有更多的中国公司能提供这样良好的氛围。

最后：

目前测试平台项目研发已经完成并且在Github开源，有兴趣的朋友可以去Github下载
https://github.com/ooqitech/ATP

不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！

一个用心码了这么多文字的人，往往渴望得到大家的认可。如果你觉得这篇文章对你有帮助，双击屏幕，给我点个赞呀！