我们都知道，「测试」是产品的真正试炼场；即使对一项软件开发工程投注了庞大的心血，如果测试不合格还是枉然，因为客户要的是「合格产品」，而不是你的「努力过程」。所以测试的重要性应该不必赘述。只不过，「知道」跟「做得到」是两回事，就如同我们都知道应该多吃青菜水果，然而还是有许多人每餐都是大鱼大肉。
许多人谈到测试，总是有满腹牢骚，因为它似乎是一件「知易行难」的麻烦工作。为何测试总是做不好？大致可归类成下述三大原因。
测试排最后
目前一般的软件开发工作，大多采用传统的「瀑布式（ Waterfall ）」流程法，也就是把开发过程分为「需求」、「分析」、「设计与撰写」、「整合」、「测试」等阶段，一个接一个依序进行。
这种方法很单纯，但导致「测试总是排在最后才进行」的状况。这种设计会产生两个状况：一是测试人员直到案子接近尾声才上工，所以往往在尚未了解整个系统架构的情况下，就一头栽进工作。二是这个时间点距离完工期实在太近，如果有什么突发状况，往往导致整个开发项目大乱或失败。
时间不够
测试做不好的第二个原因是「时间不够」，这是开发团队最常面临的问题。它其实也是上述「瀑布式」流程法把测试排在最后所导致的另一个致命伤。由于许多开发团队把大部分时间分配给前面阶段（特别是程序设计与撰写部分），只留少数时间给测试工作。然而突发状况永远无法预期，如果前面阶段因故导致工作拖延，在出货时间不能延后的情况下，后面阶段的时间就会不断地被牺牲。
所以我们常常看到，在一个预定进行八个月的软件项目里，因为前面阶段的状况百出（计算机当机、同仁生病请假、客户需求更改、开发不顺等），结果前面阶段不断占用后面阶段的时间，最后导致原本排定一个月的测试时间只剩下一周，甚至二、三天而已，根本无法测试。所以常常出现有些产品根本是在未经完整测试的情形下就贸然出货上市，把测试工作留给客户或消费者的情况。
另外还有一个与「时间不够」刚好相反的现象，就是「时间太长」。有时产品经初步测试之后发现问题丛生，实在无法交差（或是被客户退件），所以开发团队只好回头继续进行大量又重复的「测试 → 修改 → 验证」工作。如此折腾了好一阵子，最后产品终于可以验收。把这段额外时间加总起来，重新计算整体开发时间，这时才突然惊觉：「天啊，测试竟然占了将近一半的时间！」
风险太高
第三个问题是「风险太高」，也是流程设计不当所致。如文章开头所言：「测试才是产品的真正试炼场」，也就是一个项目的各种隐藏性风险，往往是透过「测试」才被完整发掘出来。但是「单向瀑布式」流程法却把测试集中在最后进行，所以它的风险容易随着开发流程的推进而越来越高；是一种相当危险的风险控管方式。
事实上，这也是许多项目在后期才突然出现成本失控或失败的重要原因。因为等到风险爆发之时，往往已经无力回天，或必须付出相当大的代价以为因应。
解决之道：采用 RUP 流程
