在瀑布式开发生命周期中，典型的一致做法是把测试部门和开发部门独立开来。
通常，测试组织与开发组织的工作会汇报给不同的领导。这样做的依据在于需求文档和设计文档都是在开发生命周期的特定阶段形成的。独立的质量保证组织能够把这些文档转换为测试计划，测试用例和测试规约。从而能够用科学合理的方法去更好更全面的对程序进行测试。这里隐含的假设是：程序员不应该测试自己编写的程序，负责程序设计的组织也不应该测试自己开发的程序。
有人认为，软件测试时一个破坏性的过程，对一个程序员来讲，要从开发软件产品突然转变到试图去发现缺陷或破坏软件是很困难的。人们认为，程序员不可能有效地测试他们自己编写的程序，因为他们基于各种原因不会主动去暴露自己的错误。往往这就是事实，也是人的共性，我经常发现有程序员总是有意识的试图去掩盖自己代码编写的问题，而不是想办法怎么去修复它。
该论点的另一个理由是，程序员对软件需求的错误理解可能会带来程序上的错误。这样，程序员在测试他们的代码时可能会存在同样的偏见，而不能像其他人那样有效的进行测试。在CMMI中会提到验证（VER）和确认（VAL）过程域，确认证明所提供的产品符合预期的使用需求，而验证说明工作产品是否适当的反映了特定需求。往往程序员的测试是验证功能的正确性，而测试团队更主要的任务是从用户角度、需求出发去对程序进行一一验证确认，即确认程序是否正确，是否满足用户的需求。所以一个功能完全正确的软件，验证通过不一定会确认通过，即不一定满足用户需求，因为这些功能可能根本就不是用户想要的。
让程序员测试自己的程序是不可能的，更因为他们有思维定势。如程序员可能对自己过度自信，认为自己编写的程序不可能有问题，从而疏于测试。或者更多从功能设计的难易程度上去实现功能，而不是基于用户预期或使用习惯。如果让一个对程序没有思维定势的人来测试可能会更有效。既然开发部门的交付物都已经文档化了，为什么不让其他人来验证确认呢？
有人认为，衡量一个开发组织是否有能力主要是看他们是否能按时、经济地开发出程序或系统。正如单个的程序员难以做到客观那样，让开发组织做到客观也是很困难的。如果要通过共同努力去发现尽量多的缺陷，那么可以想象，这个项目可能会延期或增加更多的成本。其结果一定是质量不高。
从实践来看，软件产品的质量应该由一个独立的组织来负责，应该成立产品测试或质量保证这样的组织作为独立的部门来提供服务。