首页 > 代码库 > 测试工作速记3 - 交叉测试

测试工作速记3 - 交叉测试

我如果说有一天我灵机一动想到去执行这个做法,那就是在装。这个方法大家都知道,但是不一定会去做,我们立马去做了,主要也是受了些刺激,被别人找到一些问题。于是我们就在想,我们部门有好几个测试小组,为什么我们不自己来个左右互搏呢?
正好双11刚结束的时候有点时间,那好,我们就做做看。最后的结果远超我的预期,在几天的时间里,我们累积发现了63个问题,确认的有效问题47个。有25个模块参与,14个发现了问题。当然这些问题有多种类型,包括一些体验类的问题,有很多是非常有价值的。这结果真是让人又喜又忧,不过从这个方法的角度,是完全的被证明了。

我称这个方法为“换人如换刀”,实际操作中也有一些思考和考虑,不妨拿出来探讨。
1. 很多时候,我们为了工作的效率,深入的了解业务,以及和对口产品和开发的协作,很长一段时间,每个功能点会有一个比较固定的test owner。
这样的好处显而易见,但是缺点也很明显:
- 会有审美疲劳,一些问题可能觉得不是问题
- 每个人有自己思维的盲点,很多路径考虑不到,测试用例评审也只能帮到一部分。
- 团队成员间对功能模块互相的了解不够,遇到边界的问题容易遗漏

2. 如何来划分范围?
完全的散打,每个人随意挑选自己感兴趣的模块? or 逐个的制定owner,事先完全的分好?
最后我们选取了中间路线,首选做跨地域(正好我们有两个地域的团队)的切分,两地呼唤,在这个基础上,每个人来挑选对方的模块,先到先得。
背后的思考是需要有一定的覆盖度,但是又有一定的趣味。

3. 按地域切分会引起一些不好的氛围吗?
我其实担心过,但很快不是很担心。异地团队的沟通和融合确实不容易,不过之前已经有了比较好的基础,而且大家都是站在一个比较坚实的想把事情做好的基础上,另外我们的导向上也是完全正向的。
另外, 其实有一定的竞争是一个良性的张力,就像前一篇(http://blog.csdn.net/superqa/article/details/41330225)提到的,是一个发现更多bug的动力。
实际的结果证明,这方面也没有出现问题。

就在刚刚写的时候,我在想,其实还有更多的玩法,就是可以从不同的维度划分,比如M,ipad,android,ios等等。

4. 需要feedback。
收到问题的同学需要像开发接到bug一样,给出是否是问题,如何处理等反馈。这样是跟进问题本身,也是对发现问题的人的尊重,对别人劳动的尊重。

5. 我们还设立了一个奖,发给发现bug最多的人,“乐于助人奖”,帮助别人发现TA的模块的问题,其实就是在帮助别人。 这是个导向的问题。

6. 不要求全
很难每个人都那么彻底的参与,可能因为不理解,可能因为手头有别的事情,可能真的发现不了问题。看大的方面。

7. 不用去挑战
每个正常的被别人发现问题的人都应该会有一些动力去做得更好。


下次再尝试一些不同的细节的操作,这个应该可以作为一个保留曲目。

测试工作速记3 - 交叉测试