Bug Bush

昨天整个Dev team 和QA team 参加bug bush。这是我第一次参加bug bush。

前天下午我们就放下手中的bug开始准备工作：排列test metrix，安装虚拟机，os，相应软件，看相应feature的spec和test plan。一下午安装相应的软件对有的人来说够用，但是对我来说不够。我测试的是Replicator部分，因为很忙，我直到快下班的时候才有时间开始准备工作，结果到晚上九点半的时候都没有把我要测试部分装好，这个部分我本身就不熟悉，其安装有很复杂，装过它的QA又都回去了。没办法只好第二天上班再安装了。

分给我测试的feature我一点都不熟悉，spec 和test plan没时间看，只好打印了spec回家争取能扫一眼，足足四份，几十页啊。事实上，紧张了一天，回家后根本就看不进去，何况还是英文的。

结果昨天又花了一天时间，我这部分的环境还是没装好。怎么测？不过光安装过程就发现了好几个bug，赶紧报了上去。快下班的时候就放弃了，随便点点看看能不能测出点什么。另外，应为spec，test plan都没看，根本就不知道要测什么，不过还是发现了几个一二级的bug，纯粹意外。

可能是白天太紧张了，晚上做了好多梦，梦里全是bug，bug，bug！醒了好几次，每次醒来的时候梦里发现的bug清晰可见，不过现在不记得了：）

bug bush的体会：

1. Test metrix 还是要精心设计一下的。比如一个同事要测试一个feature，但是她被分配的Role没有权限使用那个feature的全部功能，这就不周全了。

2. 这次Bug bush 安排developer 只装两台server，因为我要测Replicator，所以也装server，其他的人都是client。但是，可能是我再配置Replicator的网络的时候破坏了其中一台server，结果导致整个team突然全部都不能login进去那台server，下午3，4点的时候bug bush就进行不下去了。所以，如果是依赖于网络的话，一定得小心，最好是有应急方案。

3.这次Developer参加Bug bush原则上不能测试自己写的那部分。但是developer对别的feature有不熟悉，spec和test plan可能都没时间看。这时候测试效果就大打折扣了！这时候如果还是要求Developer也象QA一样把所有test case全部跑一边是不现实也不合理的，因为dev没测一个case需要一步一步先看描述再测试，这是很花时间的。一天的时间bug bush根本就测不了几个case，而且很有可能测试的那些case早就没有bug了，这不是浪费时间吗？

那么，该该采取怎样的策略呢？我也没想好。至少让dev象qa一样先熟悉所有的case也是不可能的，因为dev正忙于fix bug，根本就没有时间。