如果我們把項目的開發過程比作駕駛過程，產品質量就是安全駕駛，那麼測試就像是駕駛中看擋風玻璃的過程，需要融入到整個開發中。總之，產品質量需要在開發的各個環節中來保證，Bug Bash作爲常規測試的有效補充，也是產品上線前的重要一環，組織成功的Bug Bash必能使產品日趨完善。
背景故事
第一天
“感覺沒啥問題啊”
“是啊，沒啥好測的，我們系統挺穩定的”
“嗯嗯，我也覺得！”
一個小時後……
“就倆問題？既然沒有別的問題了，結束吧，回去記得這倆修修哈”
於是，在產出兩個問題後，我們一行五個人結束了年底最後一次上線前的Bug Bash。
第三天
微信羣：
組長：“各位看下郵件，明天需要緊急Hotfix這個問題”。
一個小時後
我：（思考）爲啥做了Bug Bash還沒能避免線上問題發生呢？Bug Bash如何做才能更有價值？
（注：線上Bug的鍋是我的，漏測了功能點。不過恰好引發了我對Bug Bash的思考而已<認真臉>）
什麼是Bug Bash
Bug Bash這個詞，我是來TW才聽說。第一次作爲參與者，是被分配了一份Windows IE的web測試任務，在業務還不熟悉的情況下進行了一次盲目的Bug Bash。過後，我終於對Bug Bash有了初步的認識。哦！Bug Bash 原來就是開發，測試，項目經理，需求分析師……所有相關的或者不相關想參與的人，一起放下手中活計，找個會議室玩大家來找茬啊！
組織了兩次失敗的Bug Bash
瞭解了Bug Bash是什麼後，作爲組內唯一測試，我就躍躍欲試在組內搞了一次。步驟：定會議室、定時間、發組內全員邀請郵件、準備好測試賬戶和要測哪些平臺、建了一個Trello板子給大家做記錄。（你們也是這樣組織Bug Bash的嗎？）於是在一個風和日麗的下午，我們六人組風風火火的開始了近半年第一次Bug Bash！經過一小時的奮戰產出了幾個不大不小的問題，恰好上線前有時間修復。看起來一切都恰到好處，並無異樣。
所以，年底的上線前，我們又照貓畫虎進行了文首提及的這次Bug Bash。
爲什麼說這兩次Bug Bash失敗呢？
第一 ，沒有劃分測試範圍，純粹的隨機測試導致重複測試率較高效率底下；
第二 ，未能就此次Release的功能和代碼修改的部分進行說明，使大家測試沒有側重點；
第三 ，沒有獎勵機制大家的積極性不高；
第四 ，未能在事後積極收集反饋導致同樣的問題延續到了第二次。
後來在組內的Retro中，我們組員就此也提出了很多建議，吸取了大家的建議，加上自己的反思後我又去了解了其他組組織Bug Bash的經驗，總結了關於如何組織成功Bug Bash的幾點建議。歡迎大家指正和補充。
如何成功的組織Bug Bash
- 選擇合適的時間
建議有較大Release之前兩三天進行。這樣做的好處第一是版本穩定一般不會再有新的代碼合入，第二是發現問題還會有一到兩天時間修改，改完也會有時間測試。具體時間選擇，個人更傾向下午4點以後。在即將下班的時間，大家一起約到會議室，進行一場遊戲式的Bug Bash，然後結束一天的工作，似乎聽起來比早上做完Bug Bash，下午就要開始改代碼好的多。
- 確定地點
如果有通風好，又安靜，還能曬到陽光的大會議室就太好了。頭腦清晰纔能有更多產出嘛。
- 確定參與人
雖然Bug Bash是一場測試活動，但是參與人不應該僅限於測試。我們要求組內全員參與的同時，也應該考慮到非組內成員往往會有更加新鮮的視角和思路。我們可以邀請其他團隊中有相關經驗的人，比如邀請做過類似項目的測試，瞭解該領域業務的需求分析師。參與者在技能和角色上的差異有助於發現不同類型、不同層次的缺陷。
- 準備測試設備，測試環境，測試賬戶，提單模版等
我們是支持手機的web項目，所以一般會準備安卓手機，蘋果手機，Windows筆記本，Mac筆記本。具體需要測試哪些設備根據各自項目而定，提前找好設備事半功倍。
測試環境的話我們是前後端分離項目，所以首先會和後端確認是否現在的版本是準備上生產環境的，確定可以我們會把最新的前端代碼部署到預生產環境。確保我們進行Bug Bash的環境是準生產環境版本。
根據不同權限分配不同的測試賬戶給參與人員也是很重要的，這樣可以保證每種權限的功能都被測試到。因此，作爲Bug Bash的組織者，需要提前爲大家準備測試賬號，避免使用同類型賬號遺漏測試點。
準備提單模版，我們組會在Trello上建一個Kanban供大家使用。約定好不同優先級的問題使用哪種顏色標籤。一般會有Backlog、 In Progress、Fixed、in QA、QA done、Not an issue，這幾個泳道。
- 準備特性列表
Bug Bash雖然是一場隨機測試，但是不應該只讓大家隨意點點。作爲測試，應該準備一個產品的特性列表以供大家選擇。確保我們產品中重要的特性都被覆蓋到的同時，也能很大程度減少重複性測試。
準備好列表後，測試還應該就自動化測試覆蓋不到的部分，本次Release有過修改的模塊在會前重點說明。讓大家有側重點的去測試。這是非常重要而我們之前缺失的部分，也是導致我們Bug Bash失敗的主要原因。
- 溝通與日程安排
做好上述工作後，就可以安排時間對參與者發出邀請了，我們儘量選擇適合所有參與人員的時間段和時長。
- 確定活動形式
以往參與的幾次Bug Bash我們都是拿起設備就開幹，形式=無形式。
其實爲了調動大家積極性，我們可以採取競賽形式，以個人爲單位，也可以組隊進行。提出問題較多和提出問題的嚴重級別較高者獲勝，對於獲勝者準備物質獎勵。巧克力，餅乾等小食品大家都很喜歡。也可以準備一個獎盃，類似於學生時代的流動紅旗，在每次Bug Bash後它將擁有一個新主人。
- 整理與合併
最後的時間要留給問題整理。把大家提出的問題挨個過一遍，過程中可以澄清問題避免理解誤差，同時進行問題分類。把重複性問題進行合併，排除Not a bug， 進行問題優先級排序。分類好之後，對需要解決的問題和團隊達成一致。最後將整理結果記錄併發送給團隊成員。
- 收集反饋
準備一份金數據，在會後收集大家對於本次Bug Bash的體驗和建議。有反饋才能幫助我們提升後續活動質量，除此之外反饋還承擔着我們TW人追求卓越的精神，和捍衛公司文化的重要責任。
一場成功的Bug Bash帶來的好處
我們做了那麼多準備工作，花費了那麼多人的時間經歷所做的Bug Bash價值在哪裏？
- 提早發現問題 ，避免嚴重性問題在線上環境發生。
- 幫助團隊發現更多問題。 我們參與人數較多，且是不同角色，更容易發現不同類型、不同層次的缺陷。除了缺陷外，我們也會收到很多建議性問題，潛在的需求往往由此產生。
- 幫助團隊學習 。除測試外的其他角色，往往很少使用產品，通過Bug Bash可以讓團隊其他角色作爲用戶體驗產品，深入瞭解業務。測試同學也可以從問題中累積經驗，完善測試策略，補充測試用例，這是後續提升產品質量的基石。
- 團隊建設 。平時大家各自忙於手頭工作，鮮少就產品問題進行集體交流。Bug Bash提供了這樣一個機會，讓大家一起以競賽形式玩大家來找茬，過程中還可以調侃下某些有趣的bug，說一些無關逗樂的話。這些小小的交流逐漸讓我們的團隊更加穩定。
Bug bash無所不能？
並非如此，Bug Bash也是有侷限性的。
比如，Bug Bash往往發生在開發後期，臨近發佈，這與敏捷測試中測試左移的思想不符。搭配開卡, 桌面檢查等其他敏捷實踐使用效果更佳！不過Bug Bash並不限定開發方式，其他開發模式的團隊也可以採用此實踐來完善產品。
再比如，Bug Bash中我們往往更關注較大的功能點，無法覆蓋到很多產品業務細節，比如修改某個字段所產生的影響，選擇某個下拉框才能展示某個字段，這類小的測試點往往會被忽略。這就要求測試能夠在最初測試用戶故事時設計比較詳盡的的測試用例來覆蓋這些測試點。也可以設計比較完善的自動化測試用例在迴歸測試時運行。
基於以上兩點，我們瞭解到只有Bug Bash是不能確保產品質量。
如果我們把項目的開發過程比作駕駛過程，產品質量就是安全駕駛，那麼測試就像是駕駛中看擋風玻璃的過程，需要融入到整個開發中。總之，產品質量需要在開發的各個環節中來保證，Bug Bash作爲常規測試的有效補充，也是產品上線前的重要一環，組織成功的Bug Bash必能使產品日趨完善！
作者介紹：
作者簡介：李攀，Thoughtworks 質量保證諮詢師，6年軟件測試經驗，擅長Web及接口測試，致力於敏捷軟件開發中的質量保證工作。
本文轉載自ThoughtWorks洞見。
原文鏈接：