從畢業(yè)踏入軟件測試行業(yè),偶爾在測試報告中看到“線上 0 Bug”這個的字眼。不知道何時,這樣的測試結(jié)果被當(dāng)做了一種標桿,大家好像默默的在追求這種“0 Bug”的美好測試結(jié)果。無形中大家被帶入了誤區(qū),認為專業(yè)的測試人員、全面的測試設(shè)計下不應(yīng)該有Bug,只要有問題,那么就是測試的鍋。
其實答案很明顯,大家都知道測試是沒有窮盡的,只要你愿意投入時間、人力去測試,總會發(fā)現(xiàn)大大小小的問題,但缺陷是會收斂的,前期我們可能每天發(fā)現(xiàn)20個缺陷,但隨著測試的開展,每天發(fā)現(xiàn)的缺陷數(shù)量逐漸變少。如果缺陷也遵循二八原則,投入20%成本,發(fā)現(xiàn)80%的缺陷,那么剩下的80%的成本你是否會選擇去發(fā)現(xiàn)那20%的問題呢?——視情況而定。
因此只有沒有被發(fā)現(xiàn)的Bug,沒有0 Bug。我們不需要去追求100%的完美結(jié)果,因為這是不存在的。
那么近乎完美的結(jié)果是什么?——線上沒有問題被發(fā)現(xiàn)、被吐槽。被誰?——被用戶發(fā)現(xiàn)。但隨著用戶使用次數(shù)、用戶基數(shù)的增多,幾乎不可能沒有任何問題。
研發(fā)自測,憑啥 ?
進入測試行業(yè),在參與的第一個項目的大迭代后,進行了一次缺陷分析,通過分析發(fā)現(xiàn)研發(fā)提測質(zhì)量比較差,發(fā)現(xiàn)很多明顯的重要、中等缺陷,占比30%。于是對研發(fā)提出了“自測”的要求,這是我第一次提這個詞,雖然研發(fā)看到缺陷分析的數(shù)據(jù)后,也無話可說,只能去執(zhí)行,但也能從臉上看出一絲絲的“憑啥?”。
其實,我也在想憑啥?測試人員不就是做測試嘛,研發(fā)人員不就是應(yīng)該開發(fā)嘛,那么“研發(fā)自測”這個怎么界定測試范圍呢?
如果說質(zhì)量是一個平面,平面中存在一個圓圈,圓圈內(nèi)就是研發(fā)人員自測、圓圈外就是測試人員測試,圓圈內(nèi)做的是質(zhì)量內(nèi)建,在有限的范圍(基本功能性)內(nèi)建設(shè)質(zhì)量,圓圈外做的是質(zhì)量外建,在無限的范圍(功能性、非功能性的廣度、深度)內(nèi)探索質(zhì)量,這樣來看,研發(fā)、測試共建質(zhì)量,挺好。
現(xiàn)在,隨著測試左移,也提出了測試人員通過測試技術(shù)幫助研發(fā)內(nèi)建質(zhì)量,比如自動化測試的左移。
技術(shù)推動質(zhì)量保障?
特別是近幾年,興起了技術(shù)推動質(zhì)量保障之風(fēng),我也樂死不疲的加入測試開發(fā)的隊伍當(dāng)中,但技術(shù)真的能保障質(zhì)量嗎?
先來看看我們使用技術(shù)做了些什么?,做了重復(fù)性高的測試用例的自動化;做了因為測試成本較大而沒有時間每輪迭代都會覆蓋的用例的自動化;做了測試數(shù)據(jù)構(gòu)造、測試環(huán)境檢測工具。
從上面來看,技術(shù)到底保障了什么?——效率。效率提升的背后有什么什么?——是我們將提升的效率的收益,是否投入到了測試外建(功能性、非功能性的廣度、深度)當(dāng)中。
產(chǎn)品質(zhì)量的邊界是什么?
作為一個測試人員,保障產(chǎn)品質(zhì)量當(dāng)之無愧,那么產(chǎn)品質(zhì)量是什么,沒有缺陷?
記得在2016年,第一次對產(chǎn)品進行線上用戶行為分析,在此之前我們一直認為項目質(zhì)量非常OK,因為線上缺陷少呀。
但分析結(jié)果直接顛覆三觀,產(chǎn)品各功能模塊用戶使用次數(shù)嚴重不均衡,自己所測的模塊用戶使用次數(shù)占產(chǎn)品總用戶數(shù)的20%... 原來線上缺陷少,還有另一種可能——用戶使用的少。
那么,產(chǎn)品質(zhì)量的邊界是什么?很自然,絕不僅僅是線上缺陷數(shù)量。產(chǎn)品質(zhì)量不是測試說的算,也不是研發(fā)說的算,而是用戶說的算。產(chǎn)品質(zhì)量好壞是用戶綜合體驗的反饋,是否真正的滿足用戶需求,達到用戶的使用目的,同時也是用戶使用過程中,產(chǎn)品的功能性、非功能性沒有對用戶使用操作干擾,用戶體驗流暢、用戶增長、留存等等。