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

　　在此之前，我想說明一下我觀點里的這個“專職QA”是怎么定義的。

　　1、其是很多公司成立的專門做測試的技術人員，僅測試不開發(fā)。

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

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

　　在我正在展開說明之前，我想引用兩篇文章：

　　兩篇文章

　　一篇是“關于測試和測試人員”，本文的作者Sriram Krishnan是一名程序員，曾在Yahoo和微軟工作過，開發(fā)過很多軟件，曾被紐約時報報道，寫過一本書，本文是他的一篇博客。他在文章中表達了這幾個觀點??

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

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

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

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

　　我的故事

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

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

　　在做性能測試的時候，需要Dev手把手的教怎么做性能測試，如何找到系統(tǒng)性能極限，如何測試系統(tǒng)的latency，如何觀察系統(tǒng)的負載（CPU，內存，網絡帶寬，磁盤和網卡I/O，內存換頁……）如何做Soak Test，如何觀察各個線程的資源使用情況，如何通過配置網絡交換機來模擬各種網絡錯誤，等等，等等。

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

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

　　為什么會這樣？我覺得有這么幾點原因（和鄒欣的觀點一樣）

　　1、給了QA全部測試的權力，但是沒有給相應的責任，

　　2、QA沒有體會過軟件質量出問題后的痛苦（解決線上問題的壓力），導致QA不會主動思考和改進。

　　3、QA對Dev的開發(fā)過程和技術完全不了解，增加了很多QA和Dev的溝通。

　　4、QA對軟件項目的設計和實現(xiàn)要點不了解，導致了很多不有效的測試。

　　注：我無意在這里貶低QA的能力工作。只是我看到了QA因為沒有參與開發(fā)的一些現(xiàn)實問題。

　　我的觀點

　　鄒欣對于分工出現(xiàn)的問題給出了兩點解決方法：

　　● 充分授權和信任（Empower team members）

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

　　我的觀點是，理論上正確，操作上太虛了。這像我們喊的“為人民服務”的口號一樣，沒有具體的方法，根本無法落實。

　　我無意在這里貶低QA的工作，我也無意因為這個事走向另一個極端。但是，我在現(xiàn)在公司的經歷，還有很多新興公司的做法，我越來越覺得軟件開發(fā)，真的不需要專職的QA，更不需要只寫代碼不懂做測試的專職的Dev。觀點如下：

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

　　● 開發(fā)人員本來要測試自己寫的軟件，如果開發(fā)人員不懂測試，或是對測試不專業(yè)，那么這不是一個專業(yè)的開發(fā)人員。

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

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

　　很多開發(fā)人員只喜歡寫代碼，不喜歡做測試，或是他們說，開發(fā)人員應該關注于開發(fā)，而不是測試。這個思路相當?shù)腻e誤。開發(fā)人員應該關注的是軟件質量，需要證明自己的開發(fā)成果的質量。開發(fā)人員如果都不知道怎么做測試，這個開發(fā)人員是一個不合格的開發(fā)人員。