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

　　這篇文章必然是有爭議的，我在我的微博上討論過(guò)很多次了，每次都是很有爭議的。有不同的觀(guān)點(diǎn)，有爭論總是一件好事，這樣可以引發(fā)大家的思考。所以，對于我的這篇博文，如果你贊同我的觀(guān)點(diǎn)，我會(huì )感到高興，如果你會(huì )去認真地深入思考，我也會(huì )高興，如果你反對，沒(méi)關(guān)系，可以討論。

　　在此之前，我想說(shuō)明一下我觀(guān)點(diǎn)里的這個(gè)“專(zhuān)職QA”是怎么定義的。

　　1. 其是很多公司成立的專(zhuān)門(mén)做測試的技術(shù)人員，僅測試不開(kāi)發(fā)。

　　2. 這些QA對于軟件開(kāi)發(fā)技術(shù)并不熟悉，甚至不懂。

　　我經(jīng)歷過(guò)一些公司都有專(zhuān)職的QA團隊(專(zhuān)職的測試人員)，自從上個(gè)公司我的開(kāi)發(fā)團隊在一個(gè)項目上被QA部門(mén)搞得一團糟，我越來(lái)越懷疑專(zhuān)職QA存在在意義。我的觀(guān)點(diǎn)不一定對，但請讓我鮮明地表達一下——我覺(jué)得是不需要全職的QA的，甚至不需要QA這一專(zhuān)職角色或部門(mén)，因為，不懂開(kāi)發(fā)的人必然做不好測試。就像不懂開(kāi)發(fā)的研發(fā)經(jīng)理必然管不好研發(fā)團隊一樣。我越來(lái)越覺(jué)得Dev應該應該是做測試最合適的人選，這必然是未來(lái)的趨勢 (因為我已經(jīng)看到了中國程序員的進(jìn)步，相比起10年前，今天的程序員已經(jīng)是非常全面了，再來(lái)十年，必然證明我的觀(guān)點(diǎn)是對的)。

　　在我正在展開(kāi)說(shuō)明之前，我想引用兩篇文章：

　　兩篇文章

　　一篇是 “On testers and testing”(中文翻譯)，本文的作者Sriram Krishnan是一名程序員，曾在Yahoo和微軟工作過(guò)，開(kāi)發(fā)過(guò)很多軟件，曾被紐約時(shí)報報道，寫(xiě)過(guò)《Programming Windows Azure: Programming the Microsoft Cloud》，本文是他的一篇博客。他在文章中表達了這幾個(gè)觀(guān)點(diǎn)——

　　大多數的開(kāi)發(fā)團隊并不需要一個(gè)獨立的測試角色。即使要有，那么所有的開(kāi)發(fā)時(shí)間比上所有的測試時(shí)間應該 >20:1的。。證據嗎?光看看一些從古至今最成功的軟件開(kāi)發(fā)團隊就知道了。不論是當今的Facebook，還是30年前最初的NT團隊，很多偉大的產(chǎn)品都是出自沒(méi)有或很少測試人員的團隊。

　　開(kāi)發(fā)人員應該測試自己的代碼。沒(méi)什么可說(shuō)的。背后的道理并不重要。這包括單元測試，全覆蓋的自動(dòng)化測試或手工測試或組合測試。如果你的開(kāi)發(fā)人員不能/不愿意或認為這“不歸我管”，那你需要更好的程序員。

　　另一篇文章是鄒欣的“現代軟件工程講義 9 測試 QA 的角色和分工”，這是一篇很不錯的文章。他在文章里提到了分工的必要性，比如第三方的鑒定機構，并且也指出了分工的一些問(wèn)題，比如，畫(huà)地為牢的分工，無(wú)明確責任的分工，等，這些問(wèn)題直接命中了分工的要害。我隱約覺(jué)得，我和鄒欣的很多觀(guān)點(diǎn)是相同的，我們內容上是相同的，只是形式上還有分歧。另外，我的觀(guān)點(diǎn)太鮮明了，從而容易導向極端的理解。

　　你看，我們都同意，Dev要懂測試，QA要懂開(kāi)發(fā)，只不過(guò)分工不同，既然你中有我，我中有你，那就不要分彼此了，一起攜手開(kāi)發(fā)測試吧。(另外，我個(gè)人覺(jué)得不懂開(kāi)發(fā)的測試人員不可能測試得好)

　　—- update 2012/04/13 0:28—- {

　　【 《對《我們需要專(zhuān)職QA嗎?》的回應》作者：@段念-段文韜 】

　　【 《關(guān)于“我們需要專(zhuān)職的QA嗎”》作者：@Jacky郭 】

　　}

　　我的故事

　　我再說(shuō)說(shuō)我最糟糕的QA經(jīng)歷吧，這個(gè)公司的QA部門(mén)只做測試，他們的leader覺(jué)得所有的test design和test 的過(guò)程都不需要Dev參與，他們是獨立于Dev之外的部門(mén)，他們幾乎不關(guān)心Dev的設計和實(shí)現，他們只關(guān)心能跑通他們自己設計的test case。但是去執行Test Case的時(shí)候，又需要Dev的支持，尤其在環(huán)境設置，測試工具使用，確認是否是bug方面，全都在消耗著(zhù)Dev的資源，最扯的是，他們對任何線(xiàn)上的問(wèn)題不負責，反正出了問(wèn)題由Dev加班搞定。

　　我有一次私自review他們的test case的時(shí)候，發(fā)現很多的test case這樣寫(xiě)到 – “Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”?!而在test case design的時(shí)候，沒(méi)有說(shuō)明test environment/configuration 是什么?沒(méi)有說(shuō)明test data在哪里?Test Case、Test Data、Test Configuration都沒(méi)有版本控制，還有很多Test Case設計得非常冗余(多個(gè)Test Case只測試了一個(gè)功能)，不懂得分析Function Point就做Test Design。另外，我不知道他們?yōu)槭裁茨敲礋嶂杂谠O計一堆各式各樣的Negative Test Case，而有很多Positive的Test Case沒(méi)有覆蓋到。為什么呢，因為他們不知道開(kāi)發(fā)和設計的細節，所以沒(méi)有辦法設計出Effective的Test Case，只能從需求和表面上做黑盒。

　　在做性能測試的時(shí)候，需要Dev手把手的教怎么做性能測試，如何找到系統性能極限，如何測試系統的latency，如何觀(guān)察系統的負載(CPU，內存，網(wǎng)絡(luò )帶寬，磁盤(pán)和網(wǎng)卡I/O，內存換頁(yè)……)如何做Soak Test，如何觀(guān)察各個(gè)線(xiàn)程的資源使用情況，如何通過(guò)配置網(wǎng)絡(luò )交換機來(lái)模擬各種網(wǎng)絡(luò )錯誤，等等，等等。

　　測試做得也不認真，大量的False Alarm，都是環(huán)境問(wèn)題，比如：安裝新版本后沒(méi)有重啟服務(wù)，沒(méi)有使用新的配置文件，網(wǎng)絡(luò )配置，等等，等等。

　　在項目快要上線(xiàn)前的一周，我又私自查看了一下他們的Test Result，我看到5天的Soak Test 的內存使用一直往上漲，很明顯的內存泄露，這個(gè)情況發(fā)生在2個(gè)月前，但是一直都沒(méi)有報告，我只好和我的程序員每天都加班到凌晨，趕在上線(xiàn)前解決了這個(gè)問(wèn)題。但是，QA部門(mén)的同學(xué)們就像沒(méi)發(fā)生什么事似的，依然正常上下班。哎……

　　為什么會(huì )這樣?我覺(jué)得有這么幾點(diǎn)原因(和鄒欣的觀(guān)點(diǎn)一樣)

　　1. 給了QA全部測試的權力，但是沒(méi)有給相應的責任，

　　2. QA沒(méi)有體會(huì )過(guò)軟件質(zhì)量出問(wèn)題后的痛苦(解決線(xiàn)上問(wèn)題的壓力)，導致QA不會(huì )主動(dòng)思考和改進(jìn)。

　　3. QA對Dev的開(kāi)發(fā)過(guò)程和技術(shù)完全不了解，增加了很多QA和Dev的溝通。

　　4. QA對軟件項目的設計和實(shí)現要點(diǎn)不了解，導致了很多不有效的測試。

　　注：我無(wú)意在這里貶低QA的能力工作。只是我看到了QA因為沒(méi)有參與開(kāi)發(fā)的一些現實(shí)問(wèn)題。

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