这个问题要根据项目而定，不同的项目要求不一样，也许项目是没有必要的，但是有些项目也有必要
这个问题提的着实有点尴尬。
首先，部门的定义。
假设有这样一个组织，该组织以产品为单位，成立一个一个产品的部门。每个产品部下都设有测试部和开发部。如果我们从大的部门上来说，他们都是一个产品部门的，没有分开。但从子部门来说，他们又是独立的分开的。
然后，我们看各自干的活。
开发，我们称之为开发工程师，通俗的说写代码；测试，我们称之为测试工程师，通俗的说测产品。彼此工作的核心不一样，技术要求不一样。如果让开发去做测试，或者让测试去做开发。可以吗？不是不可以，但对员工的要求太高了，最终产品或项目质量肯定会出问题，毕竟一个人的精力有限，全面发展的比率毕竟相对还是少的。
最后，我们再从从属上说。
开发和测试本身就不应该存在从属的说法。让测试从属于开发，听开发的，我相信大家都会头疼，也就是大家常说的测试被开发牵着鼻子走，缺乏影响力。然而让开发从属于测试，听测试的，产品就OK了？测试能有开发那样的编码技术吗？同样那需求该听谁的？开发站在开发的角度去分析需求，测试站在测试的角度去分析需求，本身就存在观念不一致的情况，再加上需求从业务的角度，那就乱套了。
从部门的角度来说，测试与开发可并可分，但从角色和分工上来说，大部分单位都不应该把测试与开发混为一体。为了保证项目或产品的质量，我们从各个角度出发，全面设计与体验，这样才能最大意义上做出优秀的成果。
测试与开发、需求之间存在的各种矛盾，其实是必然的，有人的地方就有矛盾。这个时候，各部门的头头，项目主管的存在的意义就体现了。有问题怕什么，总有解决的办法。需求文档有问题，规范？还是需求人员的能力？开发左右测试？那说明测试人员技能还不足，提升啊。测试人员是质量的守门员，可以用各种方式去防守，不能被开发给忽悠了，这是很重要的。但开发同样需要有坚定的立场和足够的技能，毕竟生产产品的还是开发人员。
这个问题提的着实有点尴尬。
首先，部门的定义。
假设有这样一个组织，该组织以产品为单位，成立一个一个产品的部门。每个产品部下都设有测试部和开发部。如果我们从大的部门上来说，他们都是一个产品部门的，没有分开。但从子部门来说，他们又是独立的分开的。
然后，我们看各自干的活。
开发，我们称之为开发工程师，通俗的说写代码；测试，我们称之为测试工程师，通俗的说测产品。彼此工作的核心不一样，技术要求不一样。如果让开发去做测试，或者让测试去做开发。可以吗？不是不可以，但对员工的要求太高了，最终产品或项目质量肯定会出问题，毕竟一个人的精力有限，全面发展的比率毕竟相对还是少的。
最后，我们再从从属上说。
开发和测试本身就不应该存在从属的说法。让测试从属于开发，听开发的，我相信大家都会头疼，也就是大家常说的测试被开发牵着鼻子走，缺乏影响力。然而让开发从属于测试，听测试的，产品就OK了？测试能有开发那样的编码技术吗？同样那需求该听谁的？开发站在开发的角度去分析需求，测试站在测试的角度去分析需求，本身就存在观念不一致的情况，再加上需求从业务的角度，那就乱套了。
从部门的角度来说，测试与开发可并可分，但从角色和分工上来说，大部分单位都不应该把测试与开发混为一体。为了保证项目或产品的质量，我们从各个角度出发，全面设计与体验，这样才能最大意义上做出优秀的成果。
测试与开发、需求之间存在的各种矛盾，其实是必然的，有人的地方就有矛盾。这个时候，各部门的头头，项目主管的存在的意义就体现了。有问题怕什么，总有解决的办法。需求文档有问题，规范？还是需求人员的能力？开发左右测试？那说明测试人员技能还不足，提升啊。测试人员是质量的守门员，可以用各种方式去防守，不能被开发给忽悠了，这是很重要的。但开发同样需要有坚定的立场和足够的技能，毕竟生产产品的还是开发人员。
提出独立的理由只有一个“思维不能跟着开发走”
赞一个:lol回复 8# my_shadow
朋友你好,想和你聊天！
顶......叹为观止.....
必须要分离开来，测试的思维与开发是不一样的，跟着开发走很多问题都不会发掘出来，当然也少不了与开发进行沟通。
