软件工程界一直存在这样的看法，“程序员不应该测试他们自己的代码”，原因是程序员在代码开发中形成的思维定势将不可避免的导致测试的盲区，同时，就个人感情而言，个人很难否决自己努力完成的工作成果。
这样的观念使得专业的测试团队的出现成为可能，于是，在现代软件开发中，专业测试团队的介入使得软件的质量得到了相当程度上的保障。测试成为对软件质量保证的最后哨卡，开始随着人们对软件质量和可靠性的关注而取得了日渐重要的位置。
但是，软件工程的研究同样告诉我们另外一个观点：在软件开发周期的越早期发现错误，那个错误将带来的损失将越小。 下面这些图表摘自<<实用软件度量>>(capers jones，mcgraw-hill 1991)，它列出了准备测试，执行测试，和修改缺陷所花费的时间(以一个功能点为基准)，这些数据显示单元测试的成本效率大约是集成测试的两倍 系统测试的三倍。
尽管在传统测试理论中，测试几乎已经伴随了整个开发周期：单元测试、集成测试、系统测试、验收测试。但是，更多的时候我们遇到的情况是：至少在项目开始集成之前，测试是基本不存在的。程序员不愿意在模块完成之后再花时间来写测试代码(事实上，很多程序员连文档都欠奉)，而测试人员则不会写测试代码(能写代码的话通常都已经被抓去写代码了)。事实上，即使测试人员愿意写测试代码来完成对代码的单元测试，这样的分工也是不划算的，因为这引入了额外的人与人之间的交流成本。于是我们的测试通常是在集成阶段开始进入的，于是我们不得不在这个时候在来面对可能的模块质量问题、模块设计问题以及其他许多早在那之前就应该已经解决的问题。
这个情况在传统工业里是不可想象的。你无法想象波音飞机在开始总装之前没有对它的零件进行过像样的测试，但是你却常常看到我们对一大堆没有进行过单元测试的代码进行集成。这个模块有内部逻辑错误吗?它有内存泄漏吗?它能够应付那些极端的边界条件吗?它达到了需求的要求了吗?不知道，先拼起来再说，到时候测试发现不了问题就会放我们过关的。然后你盯着每周的bug 列表看，看到bug 数渐渐下降，渐渐的接近出厂要求，然后你擦擦头上的冷汗：“感谢上帝，看来这次又过关了”。但是，难免会有一天，你的邮箱里塞满了来自用户的抱怨，告诉你你的程序又在某个你想不到的地方出了问题。
问题在哪?问题在于我们要求程序员在完成开发之后再完成一套东西的开发，而这些东西并不是要开发的软件的一部分，并且将在项目结束时被抛弃。对程序员而言，这等于叫他额外的多完成一些原本不需要的任务，这是很难被接受的，即使他能理解这样做的重要性。这是人性的弱点。那么，我们如何让测试更进一步的深入开发过程，尽可能保证软件每个组件的质量呢?这就要求我们放手让测试驱动开发的过程，让对需求的承诺直接的传递到每个组件的开发当中。
文章来源于领测软件测试网 https://www.ltesting.net/
