影响软件产品质量的因素很多，开发时间、技术、员工经验、测试方法、工作态度...还有一样我觉得是关键但却很少被人提及，追究原因就是这个因素很难真正的改变，就是开发者和测试者的关系，或者说开发团队和测试团队在一个公司的组织架构。我观察到三种组织模型：

　　1）不分你我

　　这在小软件公司颇为流行（据统计70%软件公司都是小公司）。小公司成立初期最重要的是把产品做出来，慢慢的有客户之后意识质量问题日益严重，开始注意开发后还要好好测试，再之后发现自己做的自己测的靠不住，让team其它人测；最后慢慢的张三做的李四测，李四做的张三测......这些小公司的开发团队简直就是agile team的典范啊。除了小公司，很多大公司的小产品在刚刚创立阶段，也基本沿袭这种开发/测试组织架构。

　　优点：不用多说，小而快，灵活

　　不足：这种测试停留在“够用”即可，别奢望追求完美的质量。很多时候产品是在后期客户使用中不断修修补补完善的

　　2）你输我赢

　　测试和开发处于不同的部门，或者说二者虽属于同一产品，但有着不同的goal，而这些goal又是显然对立的。以之前我工作的通信公司为例：

　　做不出来开发的责任，做出来被后期测试出来的bug太多开发的责任；

　　测不出bug或者测出的bug没有达到数量测试的责任，客户上线发现新bug测试的责任；

　　责任鲜明。记得每次release完后，我都总结bug数，然后每个bug单独做RCA，每个RCA前后耗若干小时；对严重漏到客户的bug，见到几次开发经理开发工程师和测试经理测试工程师开会讨论到底是谁的责任。

　　优点：问责！无论开发还是测试都有对产品质量都有着鲜明的责任，有压力自然有动力，潜力在战斗中才能爆发，事实证明对产品质量控制是显著的。我知道还有其它通信公司也采用这种方式。

　　不足：这种过于对立的立场甚至利益点或多或少对teamwork有影响；而软件开发过程中的创新往往需要开放、交流、团队的工作氛围；此外过于强调一些指标比如测试bug数目，有时候会导致一些无益的内耗。

　　3）你好我好大家都好

　　开发和测试有着共同的目标，大家朝着共同的目标努力着。这种类似又当运动员又当裁判员的工作模式，表现往往工作氛围异常好，开发和测试在和谐愉快的沟通中达到一个看似“共赢”的结果，比如产品永远是准时发布的。

　　优点：共同的目标，团队合作，愉快的工作氛围...这些都是优秀公司的基础；

　　不足：这种架构下，测试工作的成就感以及对测试工作的激情会降低；你会加班3个小时去寻找一个必然存在但3天才能出现的一个bug吗？除非你挑战自己，否则难，因为这种成就感这种架构下并没得到认可，大家的目标是一块准时deliver；同样，在开发和测试的“较量中”，测试往往也处于相对弱势，不是人很“弱”，而是你有必要“强”吗？此外，对产品质量问题责任不清晰，“是你责任，是我责任，最后结果大家都没责任”。

　　很难说哪种组织方式最好，这取决于不同的产品，市场的需求，甚至公司的企业文化。