測試工作速記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. 不用去挑戰

每個正常的被别人發現問題的人都應該會有一些動力去做得更好。

下次再嘗試一些不同的細節的操作，這個應該可以作為一個保留曲目。