开创中小企业的软件测试（三•实战篇）

所谓实战，无非就是你来我往。在中小型企业，所有的规则都不一定是规则，发生的事情只有两种，一种是事情找到你，一种是你去找事情。主动去找事情，起码能集中力量不至于手忙脚乱。软件测试从无到有，需要做的事情比较杂，我到现在也理不出个章法来。话说人要去做一件事情，又没有理论指导，实在是非常可怜的一件事。既然没有总纲，就求个次序吧，从重要的事情说起。

l        团队建设：首先分析下团队的主人翁，因为领头的人的许多方面直接影响到团队的具体行动。比如说，我就是个天性懒散，随遇而安的人。有这样的领导，必须要配备无风自动，秋毫必见的成员。因为本人经常性的心力交瘁，还需要组员热情四射，时不时唤起我对工作已经为数不多的执着。总之，团队是需要对内互相扶持，对外十分给力。当然人一多总有不尽如人意的地方，介于我挑剔的手下也可能看到本文，所以我的牢骚就不在这里发表了。曾经有位古人的用人的策略如下：”愚士卒之耳目，使之无知。易其事，革其谋，使人无识；易其居，迂其途，使人不得虑。”我有时候就想，古人真是too dam wise！

l        缺陷管理：建立缺陷管理的流程其实不难，随便花几百万买个QC装上就可以了，你懂的。其实这部分乏善可陈，但是我觉得缺陷管理是最重要的，也是目前我唯一弄得像模像样的的结构化的东西。提醒各位，顶住压力，把握住缺陷管理相关的所有权力，不容任何人多嘴。个人的观点是缺陷管理就是缺陷管理，不要在这上面放任何其他的东西，比如项目度量元，问题管理表之类的。

l        探索测试和测试用例：已经一年了，我还没给公司系统的写过测试用例。这不是我的责任，如果有项目经理问我用例的事，我会排专人把他的需求咬得体无完肤。其实我也希望有个测试用例的框架，主要是觉得很多测试方法没有个地方保存，怪可惜的。我们分任务都是要求做探索测试，最开始我给人讲什么是探索测试，人家都迷糊；后来我发现了这么一句话：“探索测试就是把理解被测对象，设计测试，执行测试同时进行。”发明这句话的人确实是个天才，我可以先给他们讲三个比较简单的东西，然后跟他们说，现在把三个同时做了。有时候，道理难讲，事情易做。测试阶段，人均日产bug达到两位数时，就没有人关心测试用例放在哪里了。

l        版本管理：我在番外篇里就提到过版本管理，按理说这部分应该由配置管理员去做，不过测试队列里也有测试用配置管理员。开展测试，版本先行；或者说，无版本，不测试。总之，如果开发顾不过来，就自己弄。还有一个要说的，老程序员都有一版一清bug的偏执，他们印象里测试不超过3轮。对待这样的位高权重的人，要循循善诱，让他们理解版本和测试轮次之间并没有什么必然联系。

l        最后要说个理解需求和设计的问题。一个有经验的测试人员，会尽量收集被测对象相关的各种信息，其中最重要的就是需求文档和设计文档。这些都是我们测试最主要的依据。因此，经常就会有这样的问题“这部分功能没有设计文档，怎么办？”这里我想说下，依赖倒置的原则不仅在编程中好用，工作中同样好用­­——就是没有的事情楞说成有，明明有差异楞认为是一样的。你可以这么回答类似的问题，“怎么可能没有设计呀，设计就在开发人员的脑子里，砍开就能拿出来……”