桌上电话响了，我很不耐烦的接起来，因为我知道来电话的是客户。最近几天客户总是在抱怨，抱怨的内容很一致：上线后的系统BUG很多。
BUG多熟悉的名词啊，虽然大家都知道没有不存在BUG的软件。看看微软那么多补丁大家就理解了。但是如果你的BUG达到了影响系统正常功能就麻烦了。
现在我就遇到这种麻烦。
按说现在的软件公司都是配备了质量部的（也存在偷工减料不设质量部），我们公司不例外，也有所谓的质量部。说是所谓，是因为和庙里的菩萨没什么区别。
有了质量部，所以公司在分配项目组人员时，从来不算测试人员，因为公司认为有质量部了，你们开发就是了。
本来这件事是不错，可问题就出在质量部里。
先说一下我们公司质量部里的同事们。人数不多总共4个，对付我这个项目好像是够了，你先别急，我们公司的80名开发人员，同时开的项目的大概有20多个。换算一下，平均一个人要测5个项目。
明显人手吃紧啊，但是问题还没有完，作为质量部这个成本中心，老板的算盘打的可是很精的。向质量部里投的是人民币，出来的是报告（纸和打印机还是公司的），连可乐都出不来，那还投个啥啊。
在老板低薪政策下，我们公司的质量部只能招到实习生，而且人数限定为三人再加一个有点经验的经理。这个经验还是制造行业的。真应了那句话：本来数量就不多，何况质量还不好。
而为了更好的开展质量管理工作，用老板的角度来说是为了更好的使用投到质量部的钱，质量部除了测试还要负责合同文档、项目报告、CMMI的内审（我们公司没有项目管理流程，居然通过了CMMI3）、网管、库管等工作。这回数量不多质量不好的蜡烛还是两头点。
质量部的同事，本着一个人一双手能干多少算多少的原则，“努力”工作。说努力工作是因为他们是创下了我们公司有史以来零加班记录的部门。（后来他们真的加班了一回，全公司的程序员都在传着一句话“知道吗？质量部加班了”）
现在情况明白了，这个质量部是不可能完成项目测试工作，至少是不可能达到客户要求的测试结果。
既然靠不上他们，那只能靠自己了。
我自己能做到事的从来不麻烦别人——二人转演员小沈阳
其实解决BUG并不困难，困难的是如何降低BUG的出现。因为我不会使用扔鞋或丢骰子这种“先进”的方式来预估BUG，我只能用测试，而我只能用手下的人来做这件工作，真得很羡慕神仙，他们会撒豆成兵啊。
可测试面对两大难题。
第一个问题，程序员不喜欢测试工作。
这个我可以理解。就像我当年玩《仙剑》一样，打通过一遍，还会为了里面某个道具没有得到，而重玩一次吗？我相信有人会这么做，但大多数人不会，至少我不会。所以我相信大多数程序员也不会反覆测试自己开发过的代码。
我们不是计划经济时代，讲究“干一行爱一行”，现在的口号是“爱一行才能干一行”。所以不喜欢的事肯定做不好，而且不愿意做。既然做不好那为什么要做呢？
第二个问题，测试必须需要人力和时间来做。
你必须用资源来换取质量。什么是资源，资源永远是稀缺的。在我这个项目中资源就稀缺到像科威特的水一样。这点不够喝的水，现在还要洗澡。
有困难要上，没有困难制造困难也要上。
根据现有形式，我把现在项目的阵型改变一下。
原来我的团队都在全力生产，理由是第一个里程碑必须在两个月内完成。
我的团队就像打了兴奋剂的机枪兵，拼命的冲上山头，虽然他们后面没有医护兵，但依然英勇。
而现在我要将这个阵型由全攻型改为改守兼备，这样会降低开发速度，但会解决质量问题。毕竟满是BUG的产品，客户是不会付钱的。
齐格飞（真是苦命的孩子）将一半的时间放在测试上，而身为项目经理的我，将70%时间放在测试上。其他的人每天必须进行两个小时的测试。并且是交叉测试。交叉测试为了解决程序员不愿测试自己代码的问题。但事实表面他们不光不愿测试自己的代码，还不愿测试别人的代码。
痛苦的测试（真的很痛苦）进行了两个星期，效果非常显著，近120个BUG被修正，系统稳定性得到了很大提高。代价是开发速度降为原来的一半，并且全组人员牺牲了两个周六的休息（没有加班费），而我为了哄女朋友，花掉了300元（请她吃饭）。
补丁发到客户那边，客户对于这个修改的结果还是比较满意，原因是我们随补丁发送了BUG列表给他们，客户看到120行的列表，觉得我们做了很多工作。没功劳也有苦劳啊。
但这种满意不会长久，因为客户的满意最终还是取决于产品的质量。
