BugBash，即，缺陷大掃蕩。產品版本發布前，團隊全員集中起來、共同找Bug。是軟件工程、互聯網產品開發過程中，驗證環節很重要的一個活動。

什么是Bug Bash？

Bug Bash，顧名思義就是缺陷大掃蕩，讓大家在產品版本發布前，一起集中精力來找缺陷。是軟件工程、互聯網產品開發過程中，產品驗證很重要的一個活動。通常可以由項目經理或QA主導發起。

什么時候做？

建議是在上線前，QA第二輪測試結束通過后，確保線上沒有重大bug影響試用、辦事是不變的狀態下，可以舉行Bug Bash。

但這邊有個兩難是：確實比及前面描述的狀態完成后，bug bash比較正規，團隊不會因為重大bug而block各環節的試用，并且是比較接近上線后用戶的使用狀態；但壞處是通常開發時間是很緊湊的，當到第二輪測試結束后，通常離上線也沒幾天，如果BugBash提出很多需求類的bug、新需求、大改動的部份，其實已經來不及在本版本實現，就會放入需求池或之后版本實現。經常最后BugBash很多提出的問題或需求都會越積越多，修復之日路漫漫。

當然解決方式，可以在提測后，就邀請產品策劃、交互、視覺針對產品做個驗收，確認產品是否跟設計符合，以及是否有些需求bug、新需求、改進提出，可以減少Bug Bash時的需求類bug的數量，及早讓團隊因應。

跟QA做的測試區別是什么？

有同學會問：那是不是我們可以只做Bug Bash，不需要QA了？其實QA是有更專業、更全面、更完整的測試計劃與策略，Bug Bash則可以增補QA的工作，發現一些QA可能沒發現的問題。或者當QA人力不足時，眾人一起找bug的效率也較高。

加上Bug Bash參與者多，更能發現兼容性或用戶登入、權限差異等問題， 事先就可以約定好哪些人別離使用差別瀏覽器、手機、作業系統來找問題。并且一樣米養百樣人，大家對於產品操作的理解，也會差距十萬八千里；加上多人同時協作來使用系統，這個操作的復雜度就會呈現指數級的差異，可能會發現在測試環節不容易找出的復雜bug。QA在設計測試用例只能針對功能點來測，但許多新功能點交叉加上老的功能點，復雜度也會增加，這就需要眾人齊力發現復雜性bug，使得質量更有保障。

有QA同學做測試，不做Bug Bash是可以的；但是只做Bug Bash，沒有QA則是很大問題。

為什么做Bug Bash？團隊集體試用，發現需求

可能有人覺得Bug Bash都提需求會不會走偏？其實提新需求也是很重要的，因為Bug Bash中，我們的角色就不只是研發團隊，也是以用戶的角度來看產品。如果內部團隊本身都有覺得很多需要添加的需求，那產品經理或策劃也該好好考慮調整產品的設計。網易教育產品的項目經理也針對這問題做過問卷，團隊原本都是對於在Bug Bash提建議有疑慮，問卷統計出來，大部分人還是支持在Bug Bash提需求與bug都可以。

此外在Bug Bash前，開發都只是專注在本身的部份，可能都沒有完整真正試用過整個產品，要促使團隊本身主動去試用比較難。當測試第一二輪結束后，Bug Bash是一個強制的活動，促使大家真正把本身做的產品用一遍。很多之前只是在設計、交互稿看到的都只是紙上談兵，真正用起來，才會發現問題或需求，也是看交互與案牘是否容易被大家理解。所以我負責的兩個項目，經常是新需求以及需求類的bug多過開發產生的bug數。

及時梳理，發布前的剩余事項

用戶手冊、環境、帳號等等，由于大家要開始使用，會促使團隊思考上線還缺什么。由于開發與測試同學對于產品操作、環境都很熟，但在BugBash時，視覺、交互、策劃、項目辦理都可能第一次看到成品，應該思考：用戶手冊看的懂嗎？數據庫資料有沒有準備好？等問題，讓產品上線前準備更完善。

游戲化激勵團隊

如果光只是宣導：「大家要注意質量喔」、「QA要盡量找出bug喔」，或者要求大家工作職責，可能團隊成員執行的動力就比較單薄。但藉著bug bash，其實就是一種工作游戲化，透過大家聚集一起參與，然后加一些角逐的元素，會讓大家有個沖勁要努力找出bug，比誰找的bug數最多。這邊有一點要注意，主持人項目經理或QA不消只是在旁邊不雅觀看或加油，也應該積極參與，一馬當先多找一些bug出來，來提升大家參與度。當然最后可以利用統計工具，計算一下大家的排名與bug數給予獎勵。

團隊平時本身可能會做團建，有些團隊不必然常搞活動。在這種類似游戲化的活動中，會促進團隊間相互的溝通、良性競爭，對于整體團隊建設也是很有幫手的。如果項目經理要辦Bug Bash，其實可以弄的熱鬧一點，釀成一種團建。

如何做BugBash？說明規則：準備一份ppt可以在周會上，跟團隊宣導說明：什么是bug bash、宗旨跟目的是什么、時間地點是什么、準備工作確認、游戲規則等，便利大家可以隨時查閱Bug Bash規則。問題記錄的工具：如果有用jira，先確認大家都有jira 6的權限、并可以建立一個叫Bug Bash的模塊（也可以是標簽，只要便利篩選、統計）。沒有jira也可以用云協作、Google doc、Wiki工具來代替，甚至每人發一張紙筆也一樣可行，只要便利大家紀錄，結束好統計即可。提醒大家做好準備：包孕用戶手冊、環境是否都準備好、權限都開了沒、測試是否確保重大bug修復并驗證完畢。如果有經費，準備一些點心、水果、獎品，更有助于提到大家參與的興致。會議場地：項目組如果人少且都有條記本電腦，可以借一間大會議室，便利隨時討論、合作、排除問題，讓大家能更集中投入這活動，氣氛也會更熱烈。但是如果沒有措施借到大會議室或者大家都是臺式機未便利移動也不妨，只要座位距離不遠、使用即時通訊軟件溝通，也一樣可以把BugBash做的有聲有色。統計工作：Bug Bash結束后，項目經理要統計全部issue數、有效bug數、需求數（案例見下圖）。并檢查是否有重復提交的問題，若有重復可以根據提交時間的先后挨次，決定這題算是誰的，或是各得一半的分數。然后再把bug跟需求區分開來。別的有些團隊也可以按照提bug的價值與重要程度，給予差別獎勵。當然bug bash如果經費允許，可按照差別表示，給予對應同學一些獎勵，促進大家積極參與。最后也最重要的是，Bug Bash活動之后的問題落實。團隊要開個會，大家一起整理所有提出issue的優先級：判斷到產品上線前，哪些bug是要修好的、哪些是可以留到未來修。因為Bug Bash到產品上線時間可能已經很接近，除非是很嚴重的bug，，或者是工作量小、效果大的（性價比高），可以考慮處理；其余都不該該做，這樣才能保障代碼的不變性，以及準時交付。當然這版本不修的bug、不能實現的需求，可以標示重要性為minor放到需求池，在未來版本去實現。BugBash問題反思每迭代都做，容易失去新鮮感

標簽：烏魯木齊 林芝 九江 東營 鹽城