测试 --- 背后的英雄，流程的改进

昨天又一次感受了测试人员的悲哀。

系统一有问题，领导第一个想到的就是测试人员。昨天领导关心的一个产品发现了一个bug（应该说是没有实现高农恩），就在追问：这个系统怎么测试的？测试人员平时都在干什么？当系统正常运行，甚至运行尚可的时候，都是业务设计人员、系统设计人员、开发人员的功劳，这个时候测试人员就退居2线了，甚至于退居N线了，在考评、奖励上都得不到倾斜，一旦有问题，测试人员就首当其冲，当然不让承担责任。--- 昨天的问题确实是测试中的失误，现在的问题不仅是测试的问题，昨天同样发生部署人员没有按照开发流程出的部署流程操作，造成系统的故障。这些问题累计起来，看上去问题不少，虽说都是可以避免的，但造成了对测试效果的下降，使领导对测试的成果带来怀疑。

还好昨天说了一句：有问题都是测试人员的问题，但测试人员已经发现、已经排除了多少个bug有谁知道。领导也默认接受，为测试人员稍微平反了一下。

但是从这句话中，也看到了自己工作中的失误。

测试人员排查了多少个bug，为什么不能让领导知道？如果领导知道每周测试人员测试了多少个系统、测试了多少个版本、发现了多少个bug，能够让测试的工作有一个具体的量化的数字，从一个侧面、一个系统的角度来体现测试人员的工作量，这个比口头的交流更有说服力 （这个不代表测试的工作不能改进）。

当领导不能发现某项工作的工作量时候：也是需要我们把问题和领导说明白，说清楚，领导也是需要交流、需要培训的，尤其是一项对于他看来很简单，当其实工作量非常非常大，或者涉及面很广、时间拖得很长的时候：

1.譬如目前网站的修改工作，一直以为也就几个页面，弄一下也就几个小时，工作量大一些的也就2，3天的时间； 其实修改牵涉到多个部门共同工作，弄一个会员专区，从开始到结束，用了1个多月，而整个过程中，开发人员开发的只有不到1周的时间，其他的时间都用在业务部门设计、美工美化、外网系统人员部署上面，不把这些时间统计清楚，清一色的算在开发上，说开发人员的工作效率低下，实在是真不知道怎么说了；

2.譬如目前开发的信息流项目：这个正在让测试人员把信息流的功能点用脑图的方式全部列出来---本来测试就要对这么多功能点进行测试的，做一个脑图，将功能精简一下给领导看，说明说明工作量。主要使用到这个系统的其他部门的人员目前也已经参与到培训、客户化测试阶段了，他们看到这个图都吓一跳，简单的几个字已经说明了一切：这么复杂啊，这么多功能。如果只有底下的人知道，领导不知道，干活的人又白辛苦了。

改进措施：

1. 完善测试流程：
   主要对测试的功能点、测试的覆盖面再做一次整理；尤其是经常用的功能、领导关心的功能（是不是有点太功利了，谁让领导具有一票否决权）
   
2. 测试人员的测试工作进行量化：
   将测试人员每周测试了多少系统、测试了多少版本、发现了多少bug进行统计，这样一来可以监督测试人员的工作，二来也让领导知道一下测试的工作进展、测试的工作量，要知道测试人员不是只对某个产品进行测试，公司目前可以算上产品的数量是测试人员数倍都不止，不把这个列出来，领导只看到有问题的产品，而完好的产品看不到（运行正常没有事情，没有人反映问题，领导甚至把这个产品给忘了），对整个部门的工作评价也是不利的；
3. 对每个产品进行错误统计：
   由于开发人员的因素，有些产品质量一直很好，有些产品反反复复的次数占多数，不仅占用测试人员的时间，而且开发小组本身的工作效率也提不高。通过这个统计，把每个产品的质量进行统计，作为对产品组的一个考评依据。
4. 对测试要树立一个评价体系：
   这个是最难的，如果按照bug率来进行统计，如何统计bug率？按照功能模块来限定bug数量，大功能点和小功能点包含的强度不一样的，按照代码行bug数量来统计，现在的系统泥中有我，我中有你，还真是一件麻烦事。上网看一下测试理论是怎么养的，别人是如何进行评价的。