无坚不摧 唯快不破

什么人做功能测试比较好？这是我写这篇《功能测试谁来做》的想法。

经常有人会跟我说他们公司开发过程很好，配备了独立的功能测试组，有的成立了独立的测试部门。也有顾问告诉我，要有独立的测试人员。也有相当的人想着用测试来和开发制衡。

首先我承认要有功能测试组，而且我也会在项目中采用功能测试这个环节，但是对于什么样的人能做功能测试，我有自己的看法。

对项目组来说，谁设计谁测试，既然是功能顾问、功能分析设计人员做的业务分析和设计，那么就应该由他们做功能测试，而不是新手或者对业务不熟悉的测试人员，独立的功能测试部门，因为要参与多个项目，不可能精于某一领域的业务，所以他们的测试往往只是流于表面，稍微深一些的业务就无能为力。至于开发人员能不能做测试？一看规模，二看角色合并程度，我认为如果一个人业务和技术能力都很强，就更应该将功能测试交给他，而不必增加新的人手。

最理想的功能测试人员是业务用户，但是很难抓到他们，而且他们也没有时间去做用例，再完善的场景设计和用例，也无法完全覆盖，同时基于成本，也不能无休止的进行用例编写测试应该把上线前后的两个阶段，用户验收测试和上线试运行，视作功能测试，也就是说开发期的结束不是在上线前，而是在验收后，这样做就需要定义自己的项目开发过程和开发方法。

越快将可运行的系统提交给客户越好，Agile的各个流派提供了很多成功实践，我再提提我的看法，正好也把这篇BLOG和我以前的几个联系起来：

1、业务驱动，项目组必须要有强有力的业务顾问和分析人员，做好项目策划，这个可以参考我前面说的“四种模式”。对于熟悉的业务领域，做好积累。对于不熟悉的业务领域，做好上线后反复的准备。

2、缩短原型开发时间，把上线的系统视作原型，把用户视作功能测试人员，让用户真正使用系统，提出业务细节的变更，找到错误。

3、开发人员要能业务、技术能力同样突出，省掉多余的环节，他们是士官，能指挥小组，并且也能打仗，没有业务理解和分析能力、纯粹的编码人员将被淘汰。

4、做深一个业务领域，产品化。

5、不迷信流行的开发方法论，什么样的世界观决定什么样的方法论。