回到網(wǎng)易8個(gè)月軟件測試團隊轉型實(shí)踐(6)

圖-美聊2.8-iOS手工覆蓋率

利用BugTags工具的問(wèn)題反饋

過(guò)去發(fā)現線(xiàn)上問(wèn)題無(wú)有效收集數據的手段，用戶(hù)反饋之后，需要相關(guān)人員跟進(jìn)溝通，詢(xún)問(wèn)環(huán)境、設備等諸多問(wèn)題，整個(gè)過(guò)程繁瑣，人力投入開(kāi)銷(xiāo)大，引入BugTags是為了簡(jiǎn)化Bug提交過(guò)程，記錄重現場(chǎng)景相關(guān)信息，將客戶(hù)端的大量復雜操作最大限度簡(jiǎn)化。通過(guò)白名單機制，美聊可以讓用戶(hù)打開(kāi)Bugtags搖一搖問(wèn)題，提交用戶(hù)的相關(guān)環(huán)境、設備信息，進(jìn)一步推進(jìn)排查問(wèn)題的效率。

圖-BugTag競品分析

BugBash質(zhì)量活動(dòng)

傳統的產(chǎn)品走查，產(chǎn)品、視覺(jué)、交付、運營(yíng)只對自己負責的功能部分有了解和檢查，缺乏一個(gè)需求方的整體走查。當有人發(fā)現一些功能間互相關(guān)聯(lián)的問(wèn)題時(shí)，已經(jīng)比較晚，修復成本高。引入Bug Bash（所謂Bug大掃除的活動(dòng)），在項目開(kāi)發(fā)階段的末期，專(zhuān)門(mén)劃出一個(gè)專(zhuān)門(mén)的時(shí)間段（通常1天），打破以往非技術(shù)人員未參與的做法，在這期間所有參與項目的人員（技術(shù)、產(chǎn)品、交互），集中全部精力，運用各方面的知識來(lái)搜尋項目的Bug，做到及早發(fā)現問(wèn)題。

圖-Bugbash流程

會(huì )后將問(wèn)題匯總，用以推動(dòng)開(kāi)發(fā)改進(jìn)功能。

圖-Bugbash記錄

QA數據收集

在Sprint總結會(huì )上為了讓項目成員能更加清楚了解整個(gè)Sprint的質(zhì)量、進(jìn)度問(wèn)題，從Q4開(kāi)始對每個(gè)Sprint都做了數據收集和展示。通過(guò)收集每個(gè)迭代版本的工時(shí)、bug數據，在總結會(huì )上向全體人員（技術(shù)、產(chǎn)品、視覺(jué)、交互、運營(yíng)）呈現當前版本總體質(zhì)量多維度數據，指導工作的改進(jìn)方向。

· 按照階段的bug分布展示

圖-bug分布展示

原文轉自：http://www.uml.org.cn/Test/201707191.asp