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

2022/08/03閱讀時間約 5 分鐘
Bug Fixed Illustration by Manypixels Gallery / CC BY 4.0 / Remake from the original
團隊最近因為有大型功能要發佈,因此剛完成了一次捕蟲大會(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中,而還沒輪到講問題的人若發現有與自己發現有關的內容時,可以進行補充,然後從自己的清單刪去,之後就可以不必再複述此問題。這樣一來可以大量縮減事後在整理歸納問題及開單的時間,有效讓這些問題及早進入開發管線。
將資料/程式/介面流程等類別分成不同的工作表,快速紀錄發現的問題,並排定對應的JIRA任務單

5. 其他

許多團隊會在Bug Bash的規劃中加入一些遊戲化的競爭元素,藉此提高團隊溝通與良性競爭,感覺應該會頗有趣,但本次礙於時間並沒有加入,供之後要舉辦的人可以參考!
下一篇文章我們來談談進行Bug Bash的一些經驗分享,以及過程中可以注意的小細節,也希望這篇文章對你有點幫助!
Sean Wu
Sean Wu
大學時雙主修教育、國文,研究所還念了教育政策,結果現在跑來做軟體,在資料科學領域擔任Sr. Product Division Manager。 最近熱衷於騎自行車和釣魚
留言0
查看全部
發表第一個留言支持創作者!