軟體開發流程中的補蟲大會，淺談Bug Bash (上)

2022/08/05 更新2022/08/03 發佈閱讀 6 分鐘

團隊最近因為有大型功能要發佈，因此剛完成了一次捕蟲大會（Bug Bash），趁著記憶猶新，來寫一下在舉辦過程中可以注意的一些重點。除了自己紀錄，也希望對看到文章的你有點幫助。

爲什麼要舉辦Bug Bash？

在產品/功能開發告一個段落，例如當程式在測試機交付之後，通常QA會安排一系列的人工及自動化測試，但這並非萬無一失的做法，畢竟測試人力有限，視角單一，自動化測試也不一定能涵括所有場景和流程，經過幾次之後，有時笑容就會跟著逐漸僵硬，因為你總會不斷發現一些有問題或是待修正的地方。

Bug Bash的目的就是透過集合多人的視角，在短時間裡把大家關在一個小房間(?)密集操作使用，從中找出需要改進或有疑慮之處，來補足一些QA沒有發現到的問題，接著快速紀錄這些問題後歸納分類，以利後續修正的追蹤管理，進而確保正式上線時，整體功能可以更趨完整。

因此以軟體開發來說，Bug Bash主要的目的有：

1. 抓出程式/資料/介面上的錯誤

從介面上的文字、樣式，到判斷邏輯，資料一致性等等，這些錯誤會嚴重影響到使用者獲得資訊的正確性。

例如：錯誤的樣式或文字可能會誤導使用者，讓他們難以理解該如何繼續使用，不完整的程式邏輯與資料串接則可能帶出完全不在意料之內的結果，讓使用者得到錯誤的內容，甚至讓他們失去對產品的信任。而這些通常都是上線前一定要修掉的重點項目。

2. 找出體驗不佳或可改進的地方

Bug Bash也可以作為上線前的一次易用性測試，不論是產品經理或設計師都可能有因既有概念導致的盲區，這時候就需要透過其他人的使用視角來幫助自己判斷這些操作流程，或影響體驗的因素是否有可以改進的空間。

3. 讓同仁們提早熟悉功能/產品

當功能初步脫離了開發房內的打磨，也是時候讓行銷、銷售、客服及其他同仁們進來玩一玩，熟悉熟悉了，這樣不僅能夠讓他們對產品/功能有更深入的理解，甚至可以及早預測客戶們可能會遭遇的問題。

4. 及早發現，及早治療

舉辦Bug Bash時通常距離正式上線還會有一小段時間，透過團隊發現的問題評估上線時的成效與風險後，開出優先序不同的任務清單，並確保上線時這些排序較高的重點問題有被修正。

此外，雖然名為Bug Bash，但因為在過程中所有人都是站在使用者角度去使用產品與功能，自然也會伴隨著許多新需求的產生，因此，這也是一個相當適合收集需求反饋的管道。

如何舉辦一場Bug Bash？

捕蟲大會的由來已久，不論是小時候回憶的神奇寶貝金銀版，或是動物森友會都有舉辦過類似的活動，在一定的時間內瘋狂抓蟲，並計算總分。

嗯，用在軟體開發上，其實也差不多。

1. 環境設置

軟體方面，確保開發團隊已經將功能推到測試機，並且是已經準備好可以使用的狀態。硬體方面，非常建議以實體參與的方式進行，因此先訂個大會議室，確認到時候可以塞進多少人吧。

2. 事前通知

寫一封文情並茂的信與活動邀請，告訴團隊本次Bug Bash的範圍與目的，且為何需要大家撥出時間來參加，以及如何進行、時間、地點，預計的流程，或是其他需要特別注意的事項，最後，請確保所有該參加的同仁都有收到邀請。

以本次為例，我會在信中告訴大家

因應OOOOO功能將於七月底上線 (這邊可以加入簡單的功能說明)，我們將進行第一次的Bug Bash，除了盡可能的找出各種使用與資料上的問題，並趕在上線前修復調整之外，也提前讓所有同仁對新功能有初步的認識。

本次Bug Bash預計將進行1.5到2小時，前半小時請大家密集測試，範圍包括整個功能及延伸的操作流程，找出需要改進或有疑慮之處，並快速紀錄。後續時間則會快速將這些問題歸納分類，以利後續修正的追蹤管理。

請確保在活動前，每位參與者都擁有至少一組包含OOOOO完整權限的測試帳號，此外，由於資料計算的時間較長，時間允許的前提下，建議大家在活動前一兩天就可以先送出幾個比對任務，不只預先熟悉功能，也能減少屆時塞車等待的機會。

3. 抓蟲開始

嗯？用力測啊，還在發呆？

但如果你是Bug Bash的主持人，除了掌控時間之外，有時也會需要解說一下產品功能，或是激勵參賽者們的鬥志，否則時間一拉長，就會開始有人偷休息或撐下巴發呆了。

4. 問題紀錄與追蹤方式

有一種作法是讓大家直接在JIRA上開單，再由PM彙整，但礙於時間有限(想累死我？)，我用了另一個方式進行問題紀錄，就是當開始問題回報時，輪流讓大家快速講述自己的問題，初步分類後，由另一個人進行記錄到EXCEL中，而還沒輪到講問題的人若發現有與自己發現有關的內容時，可以進行補充，然後從自己的清單刪去，之後就可以不必再複述此問題。這樣一來可以大量縮減事後在整理歸納問題及開單的時間，有效讓這些問題及早進入開發管線。