Bug Bash是一種軟體工程實踐。在產品準備發布的前夕，團隊會抽出一段固定的時間（通常是 2 到 4 小時），邀請公司內部的所有人，包括開發者、產品經理 (PM)、設計師、行銷人員、甚至財務或法務人員，暫停手邊工作，像「憤怒的終端用戶」一樣瘋狂測試產品。

它的目的不是為了取代自動化測試或專業 QA，而是利用多樣化的視角與群眾壓力，找出那些躲在角落、連開發者都沒想到的低級錯誤或體驗瑕疵。

Bug Bash 的三個核心價值：

• 視野多樣化： 工程師通常有「路徑依賴」，只會測試自己寫的邏輯。行銷或行政同事則會用「不可預測」的方式操作，這往往能點出設計上的死角。

• Dogfooding (吃自家狗食)： 強迫公司內部成員真正去使用自家產品，建立對品質的共情。

• 遊戲化與士氣： 透過競爭獎勵（如：發現最嚴重 Bug 獎、最有趣 Bug 獎），將枯燥的測試變成一場有趣的團隊競賽。
  

Bug Bash 最早起源於 1980 年代的微軟 (Microsoft)。當時微軟正在開發早期的 Windows 與 Office 產品，系統的複雜度呈現幾何倍數成長。單靠專業測試人員已經無法覆蓋成千上萬種硬體組合與操作情境。微軟的管理者發現，讓所有員工同時在不同機器上「狂操」系統，能在短時間內發現大量連邊界測試都抓不到的問題。

這種做法後來演變成一種文化儀式。在 Windows 的黃金時代，一場大型的 Bug Bash 甚至會動員數百人，配備大量的披薩與可樂，在深夜的辦公室裡進行。這種「全民皆兵」的測試邏輯，後來被蘋果（Apple）、Google 與 Meta 等科技巨頭廣泛吸收並改良。

為什麼會出現這種活動？

• 測試資源的極限： 當時的軟體規模成長飛快，專業測試人員（QA）無法窮舉所有可能的硬體組合與操作情境。

• Dogfooding（吃自家狗食）文化： 微軟推崇員工要自己使用開發中的產品。Bug Bash 正是這種文化的極致表現——讓幾百個員工同時上線「操」系統。

• 解決「隧道視野」： 開發者長期盯著同一塊程式碼，容易產生盲點。透過讓鄰座完全不懂這塊邏輯的同事來測試，能有效打破這種思維定勢。

Bug Bash 與 Mob Testing 有什麼不同？
雖然兩者都強調協作，但在執行層面有本質上的差異：

以下是將 Bug Bash 從「大家隨便玩」轉化為「專業品質保證」的流程：

第一階段：目標對齊 (Mission Alignment)

「失敗的 Bug Bash 始於定義模糊。」 在發出邀請前，必須用一句話定義成功標準，這決定了後續的測試重心與分級邏輯。以下是一些目標範例：

範例 A（側重核心價值）
確保結帳與付款流程在任何異常操作下，都不會產生壞帳或資料不一致。

範例 B（側重環境相容）
驗證本次改動在手機版與低頻寬環境下，核心功能依然保持可用。

第二階段：深度籌備 (Preparation)

(1) 活動前的準備工作，決定了 70% 的成敗。

• 版本凍結
  嚴禁邊測邊改。務必明確標示 Build Number 或 Commit ID。活動期間僅允許修復致命缺陷（Stop-ship），避免新代碼引入更多變數。

• 環境與帳號「零阻力」
  參與者的時間應花在「探索」，而非「解權限」。

• 基礎設施
  獨立測試 URL、VPN 權限、測試用 Email/簡訊替身機制。

• 帳號分配
  採用「一人一組」制，預先準備好不同權限（如：管理員、VIP、黑名單用戶）的種子資料。

• 重置機制
  確保資料「髒了」能一鍵還原，維持測試節奏。

(2) 探索章程 (Charter) 的設計
別讓大家隨機亂點。根據產品風險拆解 6–12 個 Charter，讓參與者認領：

第三階段：活動當天流程

典型時間建議：90–120 分鐘。

• 開場 (10 min)
  對齊範圍、版本、回報工具（如 Jira/Linear）以及回報規格。提醒看到問題後，回報的資訊要包含哪些： 標題格式（模組 + 問題）、重現步驟、期待結果、截圖/影片、測試帳號、環境資訊。

• 探索與獵殺 (45–90 min)
  鼓勵「刻意走歪」的策略：像是執行到一半關閉視窗、切換語系、旋轉手機螢幕、縮放比例。

遇到怪現象先用 30 秒判斷價值，值得提就補齊證據，追求「可用的缺陷」而非「情緒性回報」。

• 中場檢查 (Mid-check, 10 min)
  主持人確認是否有人環境卡住，或某個 Charter 完全沒人測到，即時進行火力調度。

• 收斂與初步分級 (20 min)
  合併重複 Bug，保留證據最完整的票。當場標記出那些「不修不能上線」的致命問題。

第四階段：後續處理與回饋 (Post-Mortem)

Bug Bash 之後最重要的一場會，就是要Bug 分診。好的分診應遵循優先級邏輯。如果找出的Bug，若多集中在某模組，代表該處可測試性差；若多為需求誤解，則應回頭修正 SBE (實例化需求) 的討論方式。

接下來我們來看一個案例，這是由 BCS Software Testing SG 所舉辦的 Bug Bas，不僅是一場單純的測試競賽，更結合了專家培訓與高強度的實戰演練。

Bug Bash | BCS Software Testing SG
https://www.youtube.com/watch?v=_bG7BVhjCLg&list=TLGGLnP15-1qeGUyNzAyMjAyNg

以下是整場活動的詳細進行過程：

(1) 賽前培訓與思維建立
活動前半段，首先由專家 Ronald 進行主題演講，引導參賽者建立正確的品質思維。他強調測試人員應從「內部視角」轉向「外部顧客視角」，並建議運用「人物誌（Persona）」來想像使用者的生活軌跡與切換設備的情境，藉此激發測試靈感。

接著，專家 Paul 分享了探索性測試的實用技巧，他將抓 Bug 比喻為「拍大腳怪的照片」，建議測試人員善用 Windows 內建的 PSR（步驟收錄程式）或 Cypress 等工具隨時錄影截圖，確保能捕捉到無法輕易重現的系統漏洞。

(2) 規則宣達與團隊分組
進入實戰階段前，主辦單位將參賽者分配至不同的虛擬討論室（Breakout Rooms）組成團隊，例如「Detectives（偵探隊）」、「Bugs R Us」、「Fantastic Five（驚奇五超人）」、「Horizon」等。

實戰測試的目標是一個名為「Candy Mapper」的網站,。為了模擬真實世界中測試人員經常面臨的狀況，主辦單位刻意給予非常模糊的測試需求。同時設立了嚴格的規則：所有回報的 Bug 或彩蛋都必須限定在該網站的網域內，若點擊連結跑到其他外部網站則不予計分。

這是一位網站設計者 Paul 非常狡猾，他故意在網站中埋藏了一些會導向「外部網站」的連結。例如，有些連結會把參賽者帶到 Paul 個人的 YouTube 頻道相關網站，有些會導向另一個名為「candymapper r2」的外部測試網站。

只有在 Candy Mapper 網域內找到的 Bug 或彩蛋才算數。如果參賽者點了連結、離開了主網站卻沒有察覺，跑到外部網站上大肆測試，那麼就算抓到再厲害的 Bug 也是 0 分。

(3) 實戰抓蟲與彩蛋尋寶
比賽開始後，各團隊在約 45 分鐘的有限時間內展開瘋狂的測試-。這場競賽的獨特之處在於，除了尋找常規的系統漏洞（例如 API 錯誤、瀏覽器相容性問題）外，網站中還埋藏了大量的經典電影彩蛋讓參賽者尋寶。

參賽者在測試過程中，陸續找出了《電子情書 (You've Got Mail)》、《愛麗絲夢遊仙境 (Alice in Wonderland)》、《蒙提·派森的聖杯 (Monty Python and the Holy Grail)》、《鬼哭神號 (Poltergeist)》甚至是《超時空奇俠 (Doctor Who)》的隱藏彩蛋。在激烈的攻防下，各團隊總共提交了多達 196 個 Bugs。

(4) 評審即時審查與計分
在參賽者抓蟲的同時，評審團（包含 Adam, Paul, Jonathan 等人）在後台進行高壓的即時審查與計分工作，主要包含三個面向：

• 剔除重複：檢查團隊是否重複提交相同的 Bug，重複項目將被給予 0 分。
• 評估質量：根據 Bug 報告的描述完整性給予評分，若描述不清或被判定非系統缺陷，則給予極低分,。
• 核對彩蛋清單：參賽者回報的電影彩蛋必須在主辦單位「預先設定的清單」內才能得分。例如有團隊在舊頁面中找到了《蝙蝠俠》的蝙蝠車，但因為不在官方設計的彩蛋清單內，因此無法獲得分數。

(5) 成績揭曉與頒獎
活動尾聲，系統關閉不讓參與者再提交，評審團結算所有積分後，宣佈了最終的贏家：

• 總積分冠軍： Detectives（偵探隊）展現了極高的敏銳度，以 328 分奪得第一名；亞軍則是獲得 310 分的 Bugs R Us。
• 最多電影彩蛋獎： Bugs R Us 團隊除了抓蟲，還找出了高達 7 個官方電影彩蛋，拿下此殊榮。
• 最佳 Bug 報告獎：由Boom Shakalaka 團隊奪得。他們針對一個連結遺失的問題，撰寫了極度專業的報告，其中包含 14 個重現步驟、10 個預期結果以及 10 個實際結果。他們甚至還透過地名選單中遺漏的「柴郡（Cheshire）」，成功推敲出《愛麗絲夢遊仙境》的柴郡貓彩蛋，令評審大為讚賞。

最後，獲勝的團隊與個人獲得了由 Global App Testing 贊助的 Amazon 禮物卡，以及由專家撰寫的《Accelerating Software Quality》與《Leading Quality》等專業書籍，為這場抓蟲大會畫下完美的句點。