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