我说：他来自的外包公司，专职做测试，我相信他是专业的。只不过咱们过去缺的太多，所以他想测试，也是巧妇难为无米之炊。咱们可以继续看看。

　　果不其然，测试人员有其独到的软件测试方法、软件理解方法。很快，测试人员对软件的理解不亚于那些多年的实施顾问，也不亚于程序员。找问题也越来越准确，越来越深入。

　　当然，其原因也在于这个团队的成长，有专职的项目经理开始书写现有功能需求修改的设计文档。过去的，没有的，让它过去，让它缺失吧，但未来，不要成为过去。现在也有专职的文案，不断在修改帮助，加深了许多。测试人员现在比文案人员理解功能更细，更深入，经常提醒文案人员应该把某句话写进帮助中，否则容易被用户忽略，是个不小心会绊倒的坑。

　　为了使测试人员更快速的了解客户应用操作方法，更细节的了解特个性的功能，我让测试人员也兼任研发部的技术支持。有服务部的小姑娘无法解决的问题，转到你这里解决。否则，在过去，服务部小姑娘老把电话转给开发人员，本来几条枪，被客户电话吵的无法安心开发。而且客户发现开发人员接听电话处理问题更有效，所以很多客户都是直接给开发人员打电话，服务部成了虚架子，而开发人员的开发进度被拖累，叫苦不迭。现在有了测试人员兼任技术支持，这下解放了开发人员。开发的质量和速度提高许多。

　　但测试人员并没有做技术支持的经验，过了段时间来和我诉苦，说现在服务部小姑娘啥也不干，都直接把电话转到他这里来，所以他现在已经无法测试了，成了专职的服务支持人员。如果再这样下去，软件质量无法保证，以后的技术支持压力更重，开发部会成为开发+服务部门。

　　我给测试人员出了三个方法： 1经常遇到的问题，做成FAQ。下一次还有小姑娘问，直接让她看FAQ，拒不回答。 2交给他们方法和思路，不替他们亲自做。亲自看着她，让她服务支持客户。一次不会，再继续这样做第二次，必须让她自己亲自会了。 3每个星期六定期培训，疑问解答。并且考试。如有讲过后考试还不会者，扣钱。

　　另外，我也对服务部下了一个考核（当时我已经统管的服务部）：你接待了多少客户问题，解决时间多长，多少个问题转给开发部技术支持了，这些问题的难度级别多高。根据这些指标来衡量服务部小姑娘们的技术解决问题能力。能力差的辞退。

　　这几招后，服务部的技术支持能力蹭蹭的提高了。真是没有鞭子不干活。测试人员兼任技术支持越做越轻松了。

　　我还把版本管理、打包发布交给了测试人员。起源在于有时候客户报告了某个BUG，程序员一看好改直接改掉了，改完后直接联系客户更新了，但是并没有更改软件版本号，也没有做新的打包。于是出现了同一个版本号软件功能表现却不同。而且，由于项目组多了，每个项目组组长都各有各的原因，有时候自己打了一个包给了客户，随便定个版本号，起的都稀奇古怪，有的叫beta版，有的叫6.0.20050203。这种情形导致了测试人员做测试的时候，开发人员说改了，测试人员说没改。开发人员说已经没有问题了，测试人员说我这里还能重复出来。于是两个人一起查，耗费了两天时间，才查出来测试人员手里的和开发人员手里的不一致。

　　我又下了几招：

　　1、开发人员不能接触客户，不能接听客户电话，也不能解决客户问题，更不能给客户更新

　　2、开发人员不能没有任务分配和设计文档擅自修改软件，否则记过处分

　　3、大家一致使用版本管理工具、BUG管理工具、需求管理工具、任务管理工具。用工具把项目经理、开发人员、测试人员、文案人员绑定在一起，按固化流程推进流转。

　　4、打包发布统一交给测试人员来做，测试人员来控制是否可以发布，发布的版本号的命名。质量达不到，有权不能发布。

　　现在，我们的测试已经能做边界测试、版本兼容性测试、系统兼容性测试、压力测试、安全测试、集成测试、破坏性测试。也已经在项目中应用全程测试，测试人员主要参与需求验证、设计验证、代码验证、文档验证、打包验证。

　　但是，我们现在还没有实现单元测试，开发人员这些人，项目却多。而且测试人员没有编程能力。我们也没有做更多的回归测试，毕竟测试人员数量配备太少，而项目并行太多。

　　看机会吧。老板越从软件上赚钱，他才会越舍得投入软件。成本永远嫌多，利润永远嫌少。

　　如果你是一名开发主管，你的老板还没有从你负责的软件中赚钱，而且是很快乐的很大规模的赚钱，而不是他靠他的人际关系和送礼吃饭支撑着，我想，他不会给你一毛钱的。你抱怨也没有用，因为你没有价值，所以投入也是没有意义。

　　先去证明你的价值吧。