網(wǎng)易方法論：手把手教你做Bug Bash（缺陷大掃蕩）

　

BugBash，即，缺陷大掃蕩。產(chǎn)品版本發(fā)布前，團隊全員集中起來、共同找Bug。是軟件工程、互聯(lián)網(wǎng)產(chǎn)品開發(fā)過程中，驗證環(huán)節(jié)很重要的一個活動。

什么是Bug Bash？

Bug Bash，顧名思義就是缺陷大掃蕩，讓大家在產(chǎn)品版本發(fā)布前，一起集中精力來找缺陷。是軟件工程、互聯(lián)網(wǎng)產(chǎn)品開發(fā)過程中，產(chǎn)品驗證很重要的一個活動。通?？梢杂身椖拷?jīng)理或QA主導(dǎo)發(fā)起。

什么時候做？

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

但這邊有個兩難是：確實比及前面描述的狀態(tài)完成后，bug bash比較正規(guī)，團隊不會因為重大bug而block各環(huán)節(jié)的試用，并且是比較接近上線后用戶的使用狀態(tài)；但壞處是通常開發(fā)時間是很緊湊的，當?shù)降诙啘y試結(jié)束后，通常離上線也沒幾天，如果BugBash提出很多需求類的bug、新需求、大改動的部份，其實已經(jīng)來不及在本版本實現(xiàn)，就會放入需求池或之后版本實現(xiàn)。經(jīng)常最后BugBash很多提出的問題或需求都會越積越多，修復(fù)之日路漫漫。

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

跟QA做的測試區(qū)別是什么？

有同學(xué)會問：那是不是我們可以只做Bug Bash，不需要QA了？其實QA是有更專業(yè)、更全面、更完整的測試計劃與策略，Bug Bash則可以增補QA的工作，發(fā)現(xiàn)一些QA可能沒發(fā)現(xiàn)的問題?；蛘弋擰A人力不足時，眾人一起找bug的效率也較高。

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

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

為什么做Bug Bash？團隊集體試用，發(fā)現(xiàn)需求

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

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

及時梳理，發(fā)布前的剩余事項

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

游戲化激勵團隊

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

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

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

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