而在另一方，测试员注重于求证和怀疑。测试员对所有设计出来的东西都不信任，他们用自己掌握的知识照亮了决策中的黑暗一角，那正是别人未知或否认的。（测试员的座右铭是：“万物皆有缺陷，我能找到它们！”）
把这两种人－乐观者和怀疑者－聚在一起，以双方才智的协同之力开发出更好的软件是可能的，但这种情况很少发生。通常每个人都在走极端，成了狭隘的程序员或测试员，充斥着乐观或悲观的情绪，却从来不愿退一步考虑双方观点中的可取之处。程序代码成为团队政治的牺牲品，在双方的隔阂间被扔来扔去。等到项目结束，团队花在争论怎样做事上的时间超出了真正做事的时间。
结束程序员和测试员间争斗的最好办法是重新确定工作目标，让他们的角色关系成为协作而不是对抗。虽然可以用许多种不同的形式组建开发团队，甚至有可能不设专职的测试员（有人说一个称职的软件工程师才是质量保证的根本），本文仍假定你属于常见的大中型开发团队，在这样的团队中有一些专职的测试或质量保障角色。
使责任与权利相符
测试员或质量保障人员面临的挑战之一是：他们通常对软件的质量负有责任，但对软件的设计却施加不了多少影响。在最糟糕的情况下，编程组的工作先于测试组数周开始，在测试组介入前已编写了大量代码。这不能算是质量保障，而是所谓的信任（“我向你保证代码质量会很高”），他们的测试实际上是在为质量打补丁（“只要你交给我，我就会尽我所能把代码质量提高”）。试图以滞后的测试、少量的资源投入来做质量保障，这其实无异于在说办不到。
最小化测试与开发间冲突的最简单的办法，就是让测试组拥有能履行其职责的足够权利。既要给他们充分授权，以便他们在软件初期设计阶段能够参与或提供反馈，也要对他们这一角色应有的限制达成共识。但如果你让测试组夹在中间，责任很大而权利很小或没有，那么他们注定会使整个项目陷入混乱而导致失败。我不是在主张由测试员统领一切，而是说他们的责任应该与他们的权利大致平衡。
我所见过的最好的团队都是在一开始就进入了他们各自的角色。测试员、程序员以及其余的人都会尽早说明他们认为项目中哪些是重要的，他们的专长如何能得以施展。如果团队里有些好主管，他们就会在如何决策上达成一致，即哪些事情适合由程序员决定，哪些事情适合由测试员决定，还有哪些是由双方或多方共同决定。
尽早开始合作
如果你希望人们在工作中能相互配合，就必须给他们充分的时间以建立起工作关系。你不会与自己不甚了解的人一起分担重要的事（设想一下你把自己最隐秘的恐惧告诉邮递员，他不会认为你是认真的；更糟糕的是，你可能再也收不到信件了）。如果这就是人类本性的真相，那你就不会对程序员不满于测试员的介入感到奇怪了。如果只在项目中的某一个月份测试员才出现并寻找缺陷，他们就会遇到阻力。程序员编写的代码的质量－这是他们的骄傲之源－被完全处于局外的人所挑战，此时测试员就会被当作威胁而不是支持。
文章来源于领测软件测试网 https://www.ltesting.net/
