有一陣子沒(méi)有寫(xiě)團(tuán)隊(duì)實(shí)踐的文章了，今天參加了一個(gè)團(tuán)隊(duì)的sprint review會(huì)議。有一些有意思的發(fā)現(xiàn)，想和大家分享一下。
2周一次的迭代，今天是最后一天，下午4:00到5:00，團(tuán)隊(duì)向PO演示了本次開(kāi)發(fā)的功能。在最后演示結(jié)束的時(shí)候，QA Lead感嘆了這次迭代中一個(gè)有趣的現(xiàn)象：
- 一個(gè)本來(lái)復(fù)雜的功能（開(kāi)發(fā)2天），覺(jué)得bug會(huì)很多。但是實(shí)際交付之后無(wú)bug。
- 一個(gè)本來(lái)簡(jiǎn)單的功能（開(kāi)發(fā)半天），覺(jué)得bug會(huì)很少。實(shí)際交付后，斷斷續(xù)續(xù)持續(xù)了3天，開(kāi)發(fā)一直在改動(dòng)。
這讓我不由得好奇起來(lái)，會(huì)后的回顧會(huì)上。和Team一起探究了一下原因：
- 復(fù)雜的功能開(kāi)發(fā)很重視，所以第一時(shí)間編寫(xiě)了測(cè)試用例。在開(kāi)發(fā)過(guò)程中一直保持測(cè)試。盡可能覆蓋所有case。于是在交付的時(shí)候，發(fā)現(xiàn)問(wèn)題很少。
- 簡(jiǎn)單的功能開(kāi)發(fā)的時(shí)候，開(kāi)發(fā)人員覺(jué)得簡(jiǎn)單，同時(shí)不知道如何對(duì)controller進(jìn)行測(cè)試編寫(xiě)，就沒(méi)有編寫(xiě)測(cè)試，單純編寫(xiě)功能代碼，導(dǎo)致本應(yīng)改動(dòng)的地方遺漏，帶來(lái)了很多問(wèn)題。
這個(gè)現(xiàn)象讓我想起了以往一直在爭(zhēng)論的“寫(xiě)B(tài)ug”和修Bug，哪個(gè)更浪費(fèi)時(shí)間？看下圖，一個(gè)很經(jīng)典的統(tǒng)計(jì)圖：
- 你會(huì)發(fā)現(xiàn)藍(lán)色線條是注入bug的時(shí)間和數(shù)量。沒(méi)錯(cuò)，就是開(kāi)發(fā)編寫(xiě)代碼的時(shí)候。有一句話說(shuō)得好，每一個(gè)bug都是開(kāi)發(fā)認(rèn)認(rèn)真真地寫(xiě)進(jìn)去的，而不是QA測(cè)出來(lái)的哦。
- 黃色線是bug被發(fā)現(xiàn)的數(shù)量和相應(yīng)的階段?？梢钥吹皆诠δ軠y(cè)試和集成測(cè)試階段最多。
- 紅色線是修復(fù)bug的成本。你會(huì)發(fā)現(xiàn)越晚發(fā)現(xiàn)越貴。
團(tuán)隊(duì)還有一個(gè)洞察：在開(kāi)發(fā)功能的同時(shí)編寫(xiě)測(cè)試，比單純開(kāi)發(fā)功能要多20%～30%的工作量。但是交付質(zhì)量更高，帶來(lái)的好處是節(jié)省了修改bug的時(shí)間，用這次迭代修改那個(gè)簡(jiǎn)單功能的bug來(lái)看，3天修改bug的時(shí)間來(lái)遠(yuǎn)遠(yuǎn)大于寫(xiě)測(cè)試那多出來(lái)的30%的工作量。
總結(jié)
“寫(xiě)bug“還是修bug，哪個(gè)更浪費(fèi)時(shí)間？相信你應(yīng)該有結(jié)論了。這里給”寫(xiě)bug“加了引號(hào)，其實(shí)是自嘲一下，開(kāi)發(fā)寫(xiě)功能的時(shí)候不就是bug被注入的階段嗎？無(wú)論從圖表還是團(tuán)隊(duì)實(shí)踐都能感受到。測(cè)試左移的重要性。寫(xiě)測(cè)試花費(fèi)的時(shí)間是值得的，不要舍不得哦。
踐行敏捷實(shí)踐，讓工作變得更美好。歡迎關(guān)注我的公眾號(hào)，交流落地經(jīng)驗(yàn)。
