如何结束测试员和程序员之间的战争

由于各自角色的着眼点不同，测试员和程序员之间自然会存在冲突。简而言之，程序员注重于创造：他们做出的东西是前所未有的。与多数创造者一样，程序员在创新和解决问题上有一种天生的乐观主义（程序员的座右铭是：“只要有足够的时间，我什么都能做出来！”）。

　　而在另一方，测试员注重于求证和怀疑。测试员对所有设计出来的东西都不信任，他们用自己掌握的知识照亮了决策中的黑暗一角，那正是别人未知或否认的。（测试员的座右铭是：“万物皆有缺陷，我能找到它们！”）

　　把这两种人－乐观者和怀疑者－聚在一起，以双方才智的协同之力开发出更好的软件是可能的，但这种情况很少发生。通常每个人都在走极端，成了狭隘的程序员或测试员，充斥着乐观或悲观的情绪，却从来不愿退一步考虑双方观点中的可取之处。程序代码成为团队政治的牺牲品，在双方的隔阂间被扔来扔去。等到项目结束，团队花在争论怎样做事上的时间超出了真正做事的时间。

　　结束程序员和测试员间争斗的最好办法是重新确定工作目标，让他们的角色关系成为协作而不是对抗。虽然可以用许多种不同的形式组建开发团队，甚至有可能不设专职的测试员（有人说一个称职的软件工程师才是质量保证的根本），本文仍假定你属于常见的大中型开发团队，在这样的团队中有一些专职的测试或质量保障角色。

使责任与权利相符

　　测试员或质量保障人员面临的挑战之一是：他们通常对软件的质量负有责任，但对软件的设计却施加不了多少影响。在最糟糕的情况下，编程组的工作先于测试组数周开始，在测试组介入前已编写了大量代码。这不能算是质量保障，而是所谓的信任（“我向你保证代码质量会很高”），他们的测试实际上是在为质量打补丁（“只要你交给我，我就会尽我所能把代码质量提高”）。试图以滞后的测试、少量的资源投入来做质量保障，这其实无异于在说办不到。

　　最小化测试与开发间冲突的最简单的办法，就是让测试组拥有能履行其职责的足够权利。既要给他们充分授权，以便他们在软件初期设计阶段能够参与或提供反馈，也要对他们这一角色应有的限制达成共识。但如果你让测试组夹在中间，责任很大而权利很小或没有，那么他们注定会使整个项目陷入混乱而导致失败。我不是在主张由测试员统领一切，而是说他们的责任应该与他们的权利大致平衡。

　　我所见过的最好的团队都是在一开始就进入了他们各自的角色。测试员、程序员以及其余的人都会尽早说明他们认为项目中哪些是重要的，他们的专长如何能得以施展。如果团队里有些好主管，他们就会在如何决策上达成一致，即哪些事情适合由程序员决定，哪些事情适合由测试员决定，还有哪些是由双方或多方共同决定。

尽早开始合作

　　如果你希望人们在工作中能相互配合，就必须给他们充分的时间以建立起工作关系。你不会与自己不甚了解的人一起分担重要的事（设想一下你把自己最隐秘的恐惧告诉邮递员，他不会认为你是认真的；更糟糕的是，你可能再也收不到信件了）。如果这就是人类本性的真相，那你就不会对程序员不满于测试员的介入感到奇怪了。如果只在项目中的某一个月份测试员才出现并寻找缺陷，他们就会遇到阻力。程序员编写的代码的质量－这是他们的骄傲之源－被完全处于局外的人所挑战，此时测试员就会被当作威胁而不是支持。

　　所以说，程序员与测试员应当从第一天起就协同工作。他们一起开会讨论想从对方那里得到什么，以及他们希望对方做哪些事情。他们会根据项目目标或工作任务列表来安排工作的优先级并做出影响双方的决策。在日常工作中，程序员总会把测试员的工作看作是帮助他提高工作质量的一种方式，这增强了他的自信心。测试员不再是挑毛病、列缺陷的局外人（“烂程序员，真烂！”），与此相反，他们成为一个局内人、一个合作者，他们对程序员的工作所给予的密切帮助无人能及。

　　或许最为重要的是，尽早建立起程序员和测试员之间的工作关系，这会打造出一个使项目能够经受艰难时刻所需的纽带。在项目后期问题出现、压力加大，他们将有一段彼此信任的经历。他们会寻求解决方案应对压力和新的挑战，而不是指责对方。

带着质量意识编程

　　通常程序员和测试员在质量的含义上有着非常不同的见解。不只是他们，人们有关质量的争论已经持续了几百年，至今也未取得多少进展（参见Pirsig的《禅与摩托车维护的艺术》）。不要指望能找到一个永远正确的答案，那是不可能的事。质量是有高度主观性的，而且对于不同的项目其含义也会不同。主管们要做的是为当前的项目在质量问题上达成一致，避免哲学式的争吵，而不是去寻求一个唯一的答案。

　　精明的团队很早就对质量进行明确。他们知道在项目后期他们需要通过测试用例找出Bug并评估进展，他们决定不等到结束的时候再去处理这些事情。可以在项目初期就做出有关质量的决策。

　　测试驱动式开发（TDD）是一种流行的在初期就引入质量管理的开发模式，它使测试及质量保障与每个功能特性的设计结为一体。测试用例（软件在发布前必须满足的条件）在编写代码前就已被创建，以确定代码应达到的条件。既然你不会蠢到开车的时候不知道要去哪儿，为什么要在你还没明确目标之前就开始编码呢（除非你喜欢在公路上闲逛或者编的是些简单代码）？

　　TDD的精髓适用于各种类型的工作。如果你能尽早确定最终要实现的各种特性并把它通知给其他人，成功的机率就会升高。这就是从各项分工的角度将结果分解，使每个人都能最大程度地运用各自的技能帮助项目达到目标。

原文转自：http://www.ltesting.net