谁来保证测试工作的质量

在一个公司或者是某个组织里面,测试人员扮演的角色通常都会被认为是软件质量的保证者,把关者,仿佛经过测试的产品都是没有任何缺陷的。但事实大家都知道,即使经过多么“完美”测试的产品,总免不了在发布以后还会发现或多或少的问题。

以前在MySpace做测试的时候,主要是写代码来测试一些接口、模块等。这样就会出现一个问题,我用一段程序A去测试层序B,那么测试代码也是程序,如何保证程序A的正确性呢?OK,我们可以写一个程序C去测试程序A,由此来保障程序A的正确性,但是程序C的正确性又由谁来保证呢?who watches the watchers?当时只有我一个人负责白盒测试,最多也就是让开发帮忙看看。其实对于一段程序,只要写的足够简单,那么就可以认为这段简单的程序的正确性是能得到保证的。所以我一直都给自己强调,单元测试的代码不要写的复杂,尽可能不用判断,让测试代码顺序执行下去。

但是对于功能测试来说,怎么样才能尽可能地保证测试的方法,测试的数据,测试的覆盖率是能达到某项标准的呢?在这次MRM 2.9 Release的测试过程中,我们引入了peer review的做法,一个功能点一般会以ticket的形式存在,每个人拿到ticket的时候首先自己设计测试用例,包括测试数据的准备,用什么样的方法等等。然后找另外一个同事来review自己的用例。这样做的好处有:

  1. 强迫自己有一个较为系统的测试用例设计,因为这个是需要给同事看,并且让别人看懂的
  2. 同事之间的knowledge share在不知不觉中就达到
  3. 两个人的review总是比一大群人坐到会议室里面要有效,帮助提高测试覆盖率,尽可能避免测试盲点
  4. 互相监督

Leave a Reply

Your email address will not be published. Required fields are marked *