第四个误区：把测试的工作交给外包厂商。
无论是交给软件公司进行软件的二次开发，还是让他们从零开始部署信息化解决方案，测试都是少不了的。不过笔者发现，很多CIO会偷懒。他们要求对方进行测试，但是，自己却在测试这个环节上应付了事，不够深入。其实，笔者以前也经常犯这种错误。
如以前笔者把ERP项目的二次开发工作外包了出去。让对方在ERP系统的原有功能上再增加一些内容。那时，笔者知道测试工作的重要性。所以要求 对方在完成某项功能之前必须对软件进行测试，并且提供相关的测试报告。但是，笔者在自己公司测试的时候，由于种种原因就比较马虎了。直接根据对方提供的测 试报告，测试了一下，觉得没问题，就过关了。但是，后来大家在用的时候，才发现问题不断。如ERP系统中，采购订单审核后就不能够再打开。但是，员工有时 候会发现采购订单有错误，需要进行修改。为此，就要求对方增加这个功能。并且在需求说明书上也指明了在什么情况下可以重新打开采购订单进行修改。对方把这 个功能开发之后，他们测试已经可以重新打开已经审核的采购订单了。笔者测试后，也可以。就签字通过了。但是，在使用中，笔者才发现，对方为了省事，就缺少 了限制，即在所有情况下都能够打开采购订单。但是，在实际工作中，如果采购单已经发生了收货作业的话，是不能够重新打开采购订单的。否则的话，采购订单跟 收货单之间就会存在差异，无法匹配。可是由于笔者的疏忽，这个漏洞就这么被放过了。后来笔者只好通过触发器来进行控制。
所以，无论如何，不能够太过于相信对方的测试工作。拿到对方交付的成果之后，一定要自己对其进行测试。一般测试的时候，可以从如下几个方面展开。
一是对于某项操作，出于安全等因素的考虑，往往都有限制条件。CIO除了要测试某项功能可以实现的同时，也需要测试，这些限制条件是否已经添加 上去。如采购单审核了确实可以重新打开修改。但是，其有限制条件。当已经部分收货了，就不能够重新打开了。为此，CIO需要新建一张采购订单，然后根据采 购订单进行收货。这么操作后，在尝试着打开采购订单，看是否可行。程序员在开发的时候，往往会忽视一些限制条件。所以这是CIO测试的重点。并且，在需求 调研的时候，最好也能够注明这些限制条件。因为在测试的时候，可能会一时记不起来所有的限制因素。而有了书面记录的话，则测试起来就会方便许多。最重要的 是，要对每个限制因素进行测试，不能够漏过一个。
二是最好有业务人员加入测试过程中。某些操作或者解决方案我们CIO用起来可能很顺手，毕竟我们有这方面的专业知识。但是员工若使用起来可能就 不会这么方便。而这些功能最重是有员工来操作的。所以这么实现合不合理，最终还是要员工来评判。为此，笔者在工作中，对他们交付的成果进行测试时，会邀请 一些有这方面经验的员工来进行测试。让他们实际操作看看，是否有问题。并且是否考虑到了所有的情况。在把某个项目外包的话，CIO最担心的就是对方设计出 来的方案是纸上谈兵，中看不中用。现在有员工进行实际操作，就可以把这种可能性大大减少。
三是要测试是否对其他作业产生影响。随着信息化管理模型越来越复杂，某项功能的建立或者更改往往会牵一发而动全身。如对收货作业进行调整的话， 则就会影响采购订单、库存数量、库存成本、应付帐款等等多个作业。所以，当对收货单的作业进行调整之后，不能够只测试收货单一部分而已。而是需要测试与其 相关的所有作业，包括采购单能否生成收货单、收货单能否正常结帐、能否与发票匹配等作业都要进行测试。虽然这个测试工作可能会比较多，但是笔者仍然认为是 必需的。只有如此，才能够确认某方面的调整是否对其他的应用产生了不良的影响。特别是把二次开发的作业不是软件提供商进行，而是其他独立的软件公司完成的 时候，更加需要这方面的测试。
测试是保障外包项目质量的最重要手段。作为CIO，在测试这方面，不能够对外包服务商期待过高。因为由于种种的限制，对方不会对成果进行全方位 的测试。这方面的工作，往往只有CIO来完成。而且，在测试过程中，条件允许的话，最好有实际的操作员加入。他们会帮助CIO评估这个解决方案的实用性。