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

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

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

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

使责任与权利相符

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