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

　

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

什么是Bug Bash？

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

什么時(shí)候做？

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

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

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

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

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

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

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

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

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

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

及時(shí)梳理，發(fā)布前的剩余事項(xiàng)

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

游戲化激勵(lì)團(tuán)隊(duì)

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

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

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

標(biāo)簽：烏魯木齊 林芝 九江 東營 鹽城