陳皓：我們需要專(zhuān)職的QA嗎?(2)

　　我的觀(guān)點(diǎn)

　　鄒欣對于分工出現的問(wèn)題給出了兩點(diǎn)解決方法：

　　● 充分授權和信任(Empower team members)

　　● 各司其職，對項目共同負責(Establish clear accountability and shared responsibility)

　　我的觀(guān)點(diǎn)是，理論上正確，操作上太虛了。這就像我們國家喊的“為人民服務(wù)”的口號一樣，沒(méi)有具體的方法，根本無(wú)法落實(shí)。

　　我無(wú)意在這里貶低QA的工作，我也無(wú)意因為這個(gè)事走向另一個(gè)極端。但是，我在現在公司的經(jīng)歷，還有很多新興公司的做法，我越來(lái)越覺(jué)得軟件開(kāi)發(fā)，真的不需要專(zhuān)職的QA，更不需要只寫(xiě)代碼不懂做測試的專(zhuān)職的Dev。觀(guān)點(diǎn)如下：

　　1) 開(kāi)發(fā)人員做測試更有效

　　● 開(kāi)發(fā)人員本來(lái)就要測試自己寫(xiě)的軟件，如果開(kāi)發(fā)人員不懂測試，或是對測試不專(zhuān)業(yè)，那么這就不是一個(gè)專(zhuān)業(yè)的開(kāi)發(fā)人員。

　　● 開(kāi)發(fā)人員了解整個(gè)軟件的設計和開(kāi)發(fā)過(guò)程，開(kāi)發(fā)人員是最清楚應該怎么測試的，這包括單元測試，功能測試，性能測試，回歸測試，以及Soak Test 等。

　　● 開(kāi)發(fā)人員知道怎么測試是最有效的。開(kāi)發(fā)人員知道所有的function point，知道fix一個(gè)bug后，哪些測試要做回歸和驗證，哪些不需要。開(kāi)發(fā)人員的技術(shù)能力知道怎么才能更好的做測試。

　　很多開(kāi)發(fā)人員只喜歡寫(xiě)代碼，不喜歡做測試，或是他們說(shuō)，開(kāi)發(fā)人員應該關(guān)注于開(kāi)發(fā)，而不是測試。這個(gè)思路相當的錯誤。開(kāi)發(fā)人員最應該關(guān)注的是軟件質(zhì)量，需要證明自己的開(kāi)發(fā)成果的質(zhì)量。開(kāi)發(fā)人員如果都不知道怎么做測試，這個(gè)開(kāi)發(fā)人員就是一個(gè)不合格的開(kāi)發(fā)人員。

　　另外，我始終不明白，為什么不做開(kāi)發(fā)的QA會(huì )比Dev在測試上更專(zhuān)業(yè)? 這一點(diǎn)都說(shuō)不通啊。

　　2)減少溝通，扯皮，和推諉

　　想想下面的這些情況你是否似曾相識?

　　● QA 做的測試計劃，測試案例設計，測試結果，總是需要Dev來(lái)評審和檢查。

　　● QA在做測試的過(guò)程中，總是需要Dev對其測試的環(huán)境，配置，過(guò)程做指導。

　　● QA總是會(huì )和Dev爭吵某個(gè)問(wèn)題是不是BUG，爭吵要不要解決。

　　● 無(wú)論發(fā)現什么樣的問(wèn)題，總是Dev去解決，QA從不fix問(wèn)題。

　　● 我們總是能聽(tīng)到，線(xiàn)上發(fā)生問(wèn)題的時(shí)候，Dev的抱怨QA這樣的問(wèn)題居然沒(méi)測出來(lái)，

　　● QA也總會(huì )抱怨Dev代碼太差，一點(diǎn)也不懂測試，沒(méi)怎么測就給hand over 給QA了。

　　● QA總是會(huì )push Dev，這個(gè)bug再不fix，你就影響我的進(jìn)度了。

　　● 等等，等等。

　　如果沒(méi)有QA，那么就沒(méi)有這么多事了，DEV自己的干出來(lái)的問(wèn)題，自己處理，沒(méi)什么好扯皮的。

　　而一方面，QA說(shuō)Dev不懂測試，另一方面Dev說(shuō)QA不懂技術(shù)，而我們還要讓他們隔離開(kāi)來(lái)，各干各的，這一點(diǎn)都不利于把Dev和QA的代溝給填平了。要讓Dev理解QA，讓QA理解Dev，減少公說(shuō)公有理，婆說(shuō)婆有理的只站在自己立場(chǎng)上的溝通，只有一個(gè)方法，那就是讓Dev來(lái)做測試，讓QA來(lái)做開(kāi)發(fā)。這樣一樣，大家都是程序員了。

　　3)吃自己的狗食

　　真的優(yōu)秀的開(kāi)發(fā)團隊都是要吃自己狗食的。這句話(huà)的意思是——如果你不能切身體會(huì )到自己干的爛事，自己的痛苦，你就不會(huì )有想要去改進(jìn)的動(dòng)機。沒(méi)有痛苦，就不會(huì )真正地去思考，沒(méi)有真正的思考，就沒(méi)有真正的進(jìn)步。

　　在我現在的公司，程序員要干幾乎有的事，從需求分析，設計，編碼，集成，測試，部署，運維，OnCall，從頭到尾，因為：

　　● 只有了解了測試的難度，你才明白怎么寫(xiě)出可測試的軟件，怎么去做測試的自動(dòng)化和測試系統。

　　● 只有自己真正去運維自己的系統，你才知道怎么在程序里寫(xiě)日志，做監控，做統計……

　　● 只有自己去使用自己的系統，你才明白用戶(hù)的反饋，用戶(hù)的想法，和用戶(hù)的需求。

　　所以，真正的工程師是能真正明白軟件開(kāi)發(fā)不單單只是coding，還更要明白整個(gè)軟件工程。只明白或是只喜歡coding的，那只是碼農，不能稱(chēng)之為工程師。

　　4)其它問(wèn)題

　　● 關(guān)于SDET。全稱(chēng)是Software Development Engineer on Test。像微軟，Google， Amazon都有這樣的職位。但我不知道這樣的職位在微軟和Google的比例是多少，在A(yíng)mazon是非常少的。那么像這樣的懂開(kāi)發(fā)的專(zhuān)職測試可以有嗎?我的答案是可以有!但是，我在想，如果一個(gè)人懂開(kāi)發(fā)，為什么只讓其專(zhuān)職做測試呢?這樣的程序員分工合理嗎?把程序員分成兩等公民有意義嗎?試問(wèn)有多少懂開(kāi)發(fā)的程序員愿意只做測試開(kāi)發(fā)呢?所以，SDET在實(shí)際的操作中，更多的還是對開(kāi)發(fā)不熟的測試人員。還是哪句話(huà)，不懂開(kāi)發(fā)的人是做不好測試的。

　　● 如果你說(shuō)Dev對測試不專(zhuān)業(yè)，不細心，不認真，那么我們同樣也無(wú)法保證QA的專(zhuān)業(yè)，細心和認真。在Dev上可能出現的問(wèn)題，在QA也也會(huì )一樣出現。而出了問(wèn)題QA不會(huì )來(lái)加班解決，還是開(kāi)發(fā)人員自己解決。所以，如果QA不用來(lái)解決問(wèn)題，那么，QA怎么可能真正的細心和認真呢?

　　● 如果你說(shuō)不要QA的話(huà)，Dev人手會(huì )不夠。你這樣想一下，如果把你團隊中現有的QA全部變成Dev，然后，大家一起開(kāi)發(fā)，一起測試，親密無(wú)間，溝通方便，你會(huì )不會(huì )覺(jué)得這樣會(huì )更有效?你有沒(méi)有發(fā)現，在重大問(wèn)題上，Dev可以幫上QA的忙，但是QA幫不上Dev的忙。

　　● 第三方中立，你會(huì )說(shuō)人總是測不好自己寫(xiě)的東西，因為有思維定式。沒(méi)錯，我同意。但是如果是Dev交叉測試呢?你可能會(huì )說(shuō)開(kāi)發(fā)人員會(huì )有開(kāi)發(fā)人員的思維定式。那這只能說(shuō)明開(kāi)發(fā)人員還不成熟，他們還不合格。沒(méi)關(guān)系，只要吃自己的狗食，痛苦了，就會(huì )負責的。

　　● 磨刀不誤砍柴功。如果你開(kāi)發(fā)的東西自己在用，那么自己就是自己天然的QA，如果有別的團隊也在用你開(kāi)發(fā)的模塊，那么，別的團隊也就很自然地在幫你做測試了，而且是最真實(shí)的測試。

　　● 你可能會(huì )說(shuō)吃狗食就是個(gè)笑話(huà)，因為如果是我，我把干爛的事，就離職走人了，讓別人去吃我的狗食。這個(gè)在現實(shí)中的確會(huì )發(fā)生，也是很現實(shí)的。但是想一想，你為什么在一開(kāi)始讓他把事干爛了?另外，如果你的團隊在設計評審和代碼評審里沒(méi)有把好關(guān)，讓某人把事給干爛了，那么這個(gè)人的離職帶來(lái)的問(wèn)題還是這個(gè)團隊來(lái)扛，于是整個(gè)團隊都在吃自己的狗食，挺公平的。痛苦過(guò)一次，你的團隊下次怎么干了，就不敢亂招人了，就不敢隨意評審代碼了，就不敢讓人只做一塊東西了。最終還是沒(méi)有逃脫吃狗食的范疇。

原文轉自：http://kjueaiud.com