于是乎，为了各自的饭碗和声誉，悲剧开始了。
测试组会竭尽全力提高测试覆盖率，报bug，宁可有少量误报，也不敢遗漏；而要提高测试覆盖率，测试组需要开发组的大力支持和配合。实践证明，没有开发人员的帮助，比如介绍哪个模块有潜在问题和复杂的逻辑分支，测试组无法独自发现很多重要的bug。
而开发组在项目后期压力会比较大，一边拼命修复bug，一边看着新bug一个个先仆后继地冒出来，感觉bug就如同苍蝇般轰都轰不走。遇到比较严重又不好修复的bug，更是倍感压力，茶不思饭不香。突然间，开发人员自己发现了一个比较严重又不好修复的bug，第二天就要交付产品，时间来不及了，而测试组还没有发现。该如何抉择呢？
a、主动报告bug，自己承担全部责任；为了这个bug，可能需要专门给产品开发一个patch，在公司上下都造成了负面影响
b、隐瞒bug，测试组最终也没有发现，产品交付使用后被客户发现了，测试组承担全部责任
c、隐瞒bug，测试组最终也没有发现，产品交付使用后客户也没有发现，皆大欢喜，在下一个版本里自己悄悄修复
公司不同，企业文化不同，奖惩激励制度评价体系不同，最终会使开发人员在一番权衡之后做出截然不同的决定，进而影响这个产品甚至整个公司。
2）组织架构
在很多大公司里，部门会按照职能来划分。测试部下辖若干测试小组，每个小组负责测试一个或者一类产品；开发部下辖若干开发小组，每个小组负责开发一个或者一类产品。测试部经理和开发部经理都直接向研发中心的经理汇报。当测试部经理和开发部经理在一些工作上意见不一致时，没有人来直接做裁决，导致互相扯皮。一个中大型研发中心同时会有至少几十个项目在运作，研发中心的经理在宏观层面上掌控全局，根本无暇顾及每个项目的细节，很多时候就任由测试组和开发组的人来互相角力了。项目经理和产品经理在不同的公司里话语权差异很大，经常无法有效调和这些矛盾。
在有些公司里，部门会根据事业部/产品线来划分。部门甲负责一个或者一类产品，下辖开发组，测试组，项目经理，产品经理，UI设计人员等。当开发组和测试组意见不一致时，由部门经理最终拿主意，对项目的成败负全部责任。这种架构下情况会好很多。
Q：如何评价测试人员的工作？
A：需要bug数量和经理的主观感受相结合。单纯依赖bug数量，就如同单纯依赖代码行数来评价开发人员一样片面。其一，Bug的数量可以掺水；其二，做性能测试的人员所报bug数要远远小于做功能测试的人员，做测试开发的人员就根本没有bug可报。
Q：在从事若干年测试工作后，大家都向哪些方向发展了？
A：根据我和身边同事们所经历过的各类公司的经验，大致有如下几种出路。
1）测试管理。管理职位是稀缺的，不是想做管理的人都能有机会去做，即使各方面能力都具备了。
2）转开发。测试转开发 比 开发转测试 的难度要大得多，越早越好，转失败的不在少数。
3）转售前售后技术支持、顾问、培训。测试的好处在于对产品的整理理解和把握，同时研发的背景对于这几个工种非常有益。
4）在测试的道路上长期走下去，做技术专家。这是大部分人的选择，不管是主动的还是无奈被动的。
