曾經(jīng)，在一個版本中，提了288個Bug，簡直刷新了記錄。
可以說，從業(yè)這么多年，遇到Bug最多的一個版本。
不過，這個項目也有其特殊之處：
1、是一個全新的項目，版本是V1.0
2、是一個全新的團隊，產(chǎn)品，開發(fā)，測試是第一次合作
3、功能多，時間緊，編碼三周完成的那種

提測完后，總體情況就是點到的地方都會報錯，不是后端500就是前端的JS錯誤。

遇上這種情況，當(dāng)時是這么解決的：

1、拿著新增的Bug數(shù)據(jù)，找測試經(jīng)理匯報，說明質(zhì)量差的問題

2、知會項目負(fù)責(zé)人，也就是當(dāng)時的產(chǎn)品同學(xué)

3、在該項目的大群（也就是包含開發(fā)經(jīng)理，測試經(jīng)理，產(chǎn)品經(jīng)理），播報每日的Bug情況，主要包含每日新增Bug數(shù)，修復(fù)Bug數(shù)，激活Bug數(shù)，關(guān)閉Bug數(shù)，并附上截圖

領(lǐng)導(dǎo)看到每日的Bug數(shù)據(jù)后，會在群里回復(fù)并催促開發(fā)同學(xué)修復(fù)Bug，同時也會強調(diào)開發(fā)同學(xué)自測的重要性。
有了領(lǐng)導(dǎo)在群里的關(guān)注，發(fā)現(xiàn)質(zhì)量有較大的改善。
修復(fù)Bug的速度快了，質(zhì)量也沒有那么差了。
最后，兩周的測試時間，終于測完上線了。
從上而下推動項目，簡直比自己推動好太多。

為了改善質(zhì)量，后續(xù)也引進了冒煙流程。
也就是在版本提測之前，開發(fā)，測試，產(chǎn)品約個會議室，大家一起，由測試同學(xué)現(xiàn)場冒煙，如果主體功能通過，才能進入測試，否則，直接打回。

以后，再也沒有出現(xiàn)接近300個Bug的版本了。

劃重點：

1、提前介入。

引入冒煙流程，冒煙通過才準(zhǔn)進入測試，否則打回。

2、學(xué)會向上管理，適時匯報。

自己在只有開發(fā)測試的小群去推進項目，一般沒有什么效果。在大群，借助領(lǐng)導(dǎo)的力量，效果可以說相當(dāng)不錯，省時省力。

原創(chuàng)文章，轉(zhuǎn)載請注明出處~