以下爲文章原文：
http://www.iteye.com
這個文章必然是有爭議的，我在我的微博上討論過很多次了，每次都是很有爭議的。對於不同的觀點，有爭論總是一件好事，這樣可以引發大家的思考。所以，對於我的這篇博文，如果你贊同我的觀點，我會感到高興；如果你會去認真地深入思考，我也會高興；如果你反對，沒關係，可以討論。
在此之前，我想先說明一下我觀點裏的這個“專職QA”是怎麼定義的：
很多公司成立的專門做測試的技術人員，僅測試不開發。
這些 QA 對於軟件開發技術並不熟悉，甚至不懂。
我之前供職過的公司幾乎都有專職的QA團隊（專職的測試人員）。自從在上個公司，我的開發團隊在一個項目上被QA部門搞得一團糟後，我就越來越懷疑專職QA存在的意義。我的觀點不一定對，但請讓我鮮明地表達一下——企業不需要全職的QA，甚至不需要QA這一專職角色或部門。因爲，不懂開發的人必然做不好測試，就像不懂開發的研發經理必然管不好研發團隊一樣。現在，我越來越覺得Dev應該應該是做測試最合適的人選，而這也必然是未來的趨勢（因爲我已經看到了中國程序員的進步，相比起10年前，今天的程序員已經是非常全面了，再來十年，必然證明我的觀點是對的）。
一、兩篇文章
在我正在展開說明之前，我想先引用兩篇文章。一篇是《On testers and testing》(點擊查看中文翻譯)。本文的作者Sriram Krishnan是一名程序員，曾在Yahoo和微軟工作過，開發過很多軟件，寫過一本書，並曾接受過紐約時報的採訪。本文是他的一篇博客。他在文章中表達了以下這幾個觀點：
開發人員應該測試自己的代碼。這沒什麼可說的。背後的道理並不重要。這包括單元測試，全覆蓋的自動化測試、手工測試或組合測試等。如果你的開發人員不能、不願意或認爲這“不歸我管”，那你需要更好的程序員。
另一篇文章是鄒欣的《現代軟件工程講義9 測試 QA 的角色和分工》。這是一篇很不錯的文章。他在文章裏提到了分工的必要性，比如第三方的鑑定機構。並且也指出了分工的一些問題，比如畫地爲牢的分工、無明確責任的分工等等。這些問題直接命中了分工的要害。我隱約覺得，我和鄒欣的很多觀點是相同的，我們在內容上是相同的，只是形式上還有分歧。另外，我的觀點太鮮明瞭，從而容易引起極端的理解。
你看，我們都同意，Dev要懂測試，QA要懂開發，只不過分工不同。既然你中有我，我中有你，那就不要分彼此了，一起攜手開發測試吧。另外，我個人覺得不懂開發的測試人員不可能測試得好。
二、我的故事
我再說說我最糟糕的QA經歷吧。之前我在一家公司工作，這家公司的QA部門只做測試。他們的leader覺得所有的test design和test 的過程都不需要Dev參與，他們是獨立於Dev之外的部門，他們幾乎不關心Dev的設計和實現。他們只關心能跑通他們自己設計的測試用例。但是去執行測試用例的時候，又需要Dev的支持，尤其在環境設置、測試工具使用、確認是否是bug方面，全都在消耗着Dev的資源。最讓我感到絕望的是：他們對任何線上的問題不負責，反正出了問題由Dev加班搞定。
我有一次私自review他們的測試用例的時候，發現很多的測試用例這樣寫到：“Expected Result：Make sure every thing is fine”。什麼叫“Every thing is fine”？！而在測試用例設計的時候，沒有說明測試環境是什麼，沒有說明測試數據在哪裏，測試用例、測試數據、測試配置都沒有版本控制，還有很多測試用例設計得非常冗餘（多個測試用例只測試了一個功能），不懂得分析Function Point就做測試設計。
另外，我不知道他們爲什麼那麼熱衷於設計一堆各式各樣的負向測試用例，而有很多正向測試用例沒有覆蓋到。爲什麼呢，因爲他們不知道開發和設計的細節，所以沒有辦法設計出高效的測試用例，只能從需求和表面上做黑盒。
在做性能測試的時候，需要Dev手把手的教怎麼做性能測試，如何找到系統性能極限，如何測試系統的latency，如何觀察系統的負載（CPU、內存、網絡帶寬、磁盤和網卡I/O、內存換頁……），如何做Soak Test，如何觀察各個線程的資源使用情況，如何通過配置網絡交換機來模擬各種網絡錯誤等等，等等。
測試做得也不認真，大量的False Alarm，都是環境問題。比如：安裝新版本後沒有重啓服務，沒有使用新的配置文件，網絡配置等等，等等。
在項目快要上線前的一週，我又私自查看了一下他們的測試結果，我看到5天的Soak Test 的內存使用一直往上漲，很明顯這是內存泄露。這個情況發生在2個月前，但是一直都沒有報告，我只好和我的程序員每天都加班到凌晨，趕在上線前解決了這個問題。但是，QA部門的同學們就像沒發生什麼事似的，依然正常上下班。哎……
爲什麼會這樣？我覺得有這麼幾點原因（和鄒欣的觀點一樣）：
給了QA全部測試的權力，但是沒有給相應的責任。
QA沒有體會過軟件質量出問題後的痛苦（解決線上問題的壓力），導致QA不會主動思考和改進。
QA對Dev的開發過程和技術完全不瞭解，增加了很多QA和Dev的溝通。
QA對軟件項目的設計和實現要點不瞭解，做了很多無效的測試。
注：我無意在這裏貶低QA的能力和工作，只是我看到了QA因爲沒有參與開發的一些現實問題。
三、我的觀點
鄒欣對於分工出現的問題給出了兩點解決方法：
充分授權和信任（Empower team members）
各司其職，對項目共同負責（Establish clear accountability and shared responsibility）
我的觀點是：理論上正確，操作上難以實現。
我無意在這裏貶低QA的工作，我也無意因爲這個事走向另一個極端。但是，我在現在公司的經歷，還有很多新興公司的做法，讓我越來越覺得軟件開發，真的不需要專職的QA，更不需要只寫代碼不懂做測試的專職的Dev。觀點如下：
1、開發人員做測試更有效
開發人員本來就要測試自己寫的軟件。如果開發人員不懂測試，或是對測試不專業，那麼這就不是一個專業的開發人員。
開發人員瞭解整個軟件的設計和開發過程，開發人員是最清楚應該怎麼測試的，這包括單元測試、功能測試、性能測試、迴歸測試以及Soak Test 等。
開發人員知道怎麼測試是最有效的。開發人員知道所有的function point，知道修復一個bug後，哪些測試要做迴歸和驗證，哪些不需要。開發人員的技術能力知道怎麼才能更好的做測試。
很多開發人員只喜歡寫代碼，不喜歡做測試，或者如他們所說，開發人員應該關注於開發，而不是測試。這個思路相當的錯誤。開發人員最應該關注的是軟件質量，需要證明自己的開發成果的質量。開發人員如果都不知道怎麼做測試，這個開發人員就是一個不合格的開發人員。
另外，我始終不明白，爲什麼不做開發的QA會比Dev在測試上更專業？ 這一點都說不通啊。
2、減少溝通、扯皮和推諉
想想下面的這些情況你是否似曾相識？
QA做的測試計劃、測試案例設計、測試結果，總是需要Dev來評審和檢查。
QA在做測試的過程中，總是需要Dev對其測試的環境、配置和過程做指導。
QA總是會和Dev爭吵某個問題是不是bug，爭吵要不要解決。
無論發現什麼樣的問題，總是Dev去解決，QA從不解決問題。
我們總是能聽到，線上發生問題的時候，Dev抱怨QA這樣的問題居然沒測出來。
QA也總會抱怨Dev代碼太差，一點也不懂測試，沒怎麼測就給hand over 給QA了。
QA總是會催促 Dev：這個bug再不修復，你就影響我的進度了！
如果沒有QA，那麼就沒有這麼多事了，DEV遇到自己的問題，自己處理，沒什麼好扯皮的。
一方面，QA說Dev不懂測試；另一方面Dev又說QA不懂技術。而我們還要讓他們隔離開來，沒有溝通。我們應該讓Dev理解QA，也要讓QA理解Dev，減少公說公有理，婆說婆有理的現象出現。
3、吃自己的狗食
真正優秀的開發團隊都是要吃自己狗食的。這句話的意思是：如果你不能切身體會到自己糟糕的開發成果帶來的痛苦，就不會真正地去思考；沒有真正的思考，就沒有真正的進步。
在我現在的公司，程序員要幹幾乎所有的事：需求分析、設計、編碼、集成、測試、部署、運維、OnCall。因爲：
只有瞭解了測試的難度，你才明白怎麼寫出可測試的軟件，怎麼去做測試的自動化和測試系統。
只有自己真正去運維自己的系統，你才知道怎麼在程序裏寫日誌、做監控、做統計……
只有自己去使用自己的系統，你才明白用戶的反饋、用戶的想法和用戶的需求。
所以，優秀的程序員深知這一點：軟件開發不單單只是編碼，還更明白整個軟件工程。只明白或是隻喜歡編碼的，那隻能稱之爲碼農，不能稱之爲軟件工程師。
4、其它問題
關於SDET（全稱是Software Development Engineer on Test）。像微軟、Google、Amazon都有這樣的職位。但我不知道這樣的職位在微軟和Google的比例是多少。那麼像這樣的懂開發的專職測試可以有嗎？我的答案是可以有！但是，我在想，如果一個人懂開發，爲什麼只讓其專職做測試呢？這樣分工合理嗎？把程序員分成兩等公民有意義嗎？試問有多少懂開發的程序員願意只做測試開發呢？所以，SDET在實際的操作中，更多的還是對開發不熟的測試人員。
如果你說Dev對測試不專業、不細心、不認真，那麼我們同樣也無法保證QA的專業、細心和認真。Dev遇到的的問題，QA可能也會遇到。而出了問題QA不會來加班解決，還是開發人員自己解決。所以，如果QA不用來解決問題，那麼，QA怎麼可能真正的細心和認真呢？
如果你說不要QA的話，Dev人手會不夠。你這樣想一下，如果把你團隊中現有的QA全部變成Dev。然後，大家一起開發，一起測試，親密無間，溝通方便，你會不會覺得這樣會更有效？你有沒有發現，在重大問題上，Dev可以幫上QA的忙，但是QA幫不上Dev的忙。
第三方中立，你會說程序員總是測不好自己寫的東西，因爲有思維定式。沒錯，我同意。但是如果是Dev交叉測試呢？你可能會說開發人員會有開發人員的思維定式。那這隻能說明開發人員還不成熟，他們還不合格。沒關係，只要吃自己的狗食，痛苦了，就會負責的。
磨刀不誤砍柴功。如果你開發的東西自己在用，那麼自己就是自己天然的QA；如果有別的團隊也在用你開發的模塊，那麼，別的團隊也就很自然地在幫你做測試了，而且是最真實的測試。
你可能會說吃狗食就是個笑話，倘若換成我，項目做得不好，就離職走人，讓後來者去吃我的狗食。這個的確是這樣的，但是想一想，你爲什麼在一開始不提醒他？另外，如果你的團隊在設計評審和代碼評審裏沒有把好關，讓某位程序員矇混過關，那麼這爲程序員離職後帶來的問題還是要由你的團隊來解決。於是整個團隊都在吃自己的狗食，這很公平。痛苦過一次，你的團隊就不敢隨意招人、不敢隨意評審代碼、不敢讓某位員工只做一塊東西了。而這最終還是沒有逃脫吃狗食的範疇。
關於自動化測試。這是一個機械的重複勞動。我想讓測試人員思考一下，你是否在做這樣的事？如果你正在做這樣的事，那麼，你要思考一下你的價值了。但凡是重複性比較高的機械性勞動，總有一天要被機器所取代。
關於線上測試。我們都知道，無論自己內測的怎麼樣，到了用戶那邊，總是會有一些測試不到的東西。所以，有些公司可能會做用戶驗收測試（做產品的公司會叫Beta測試）。無論怎麼樣，你總是要上生產線做測試的。對於互聯網企業來說，生產線上測試有的玩A/B 測試，有的玩部分用戶測試。比如，新上線的功能只有10%的用戶可以訪問得到，這樣不會因爲出問題讓全部用戶受到影響。做這種測試的人必然是開發人員。
評論：
30 樓 javer 2012-04-16 17:11
29 樓 surelei 2012-04-14 21:38
QA和測試還沒搞清楚。。。
28 樓 liusu 2012-04-13 13:34
確實開發人員的工作重心決定了他不可能完整而且系統的對整個系統的進行鉅細無遺的測試。但是有個關鍵是現在好的測試人員太難找了。 我經過的兩個項目QA完全不懂編碼而且也沒有興趣接觸編碼，這樣即使是使用一些很自動的工具（類似錄製測試用例）他們也沒有辦法接手。 最終只能分出部分開發人員去實現QA已經寫好的TestCase。
27 樓 streamone 2012-04-13 09:05
“沒搞過測試也不會測試”！那貴公司的“她們”是怎麼被招進公司的？
QA不做測試就像測試不去幹QA該乾的活兒，做好自己職責內的事兒，你懂？
26 樓 allloveend 2012-04-12 19:42
LZ這篇帖子完全跑題,
25 樓 kyfxbl 2012-04-12 16:26
個人感覺測試還是有用的，但是好的測試少。QA根本沒用，就是混日子的
24 樓 andyflyingcat 2012-04-12 14:14
不過也難怪，很多公司規模也不小，TMD也分不清這些角色職責。主要是sb領導太多
23 樓 grantren 2012-04-12 13:49
很多公司，理想狀態的開發測試比例爲1:1.
另外在很多公司，QA式獨立的部門，並不是測試。
22 樓 mylazygirl 2012-04-12 13:44
讓我想到了這張圖
http://imgsrc.baidu.com/forum/pic/item/6a600c338744ebf846b2be80d9f9d72a6159a74a.jpg
21 樓 faye.feelcool 2012-04-12 13:10
主要還是國情使然，牛人作爲一種稀缺資源，不是那麼的多，所以牛人在很多公司都被放在開發上。然後就是由什麼cmm，cmmi等認證熱，將一堆什麼還不明白的新人推向QA領域。
很多公司，做測試的都是因爲做開發不適合才放到測試中的，而不是他在測試上有天分。
所以，不要怨恨，不要怨念。而應該合作，和體諒。在測試不夠強大時候，開發的確要自行把關，測試只是最後一步，發佈前的最後一到工序而已，不要把一切都押寶在最後一刻。而且，作爲開發人員也得有清醒的認識，自己纔是一切的根源。
要不要專職的QA，看公司規模，看項目規模，看技術實力，沒有豐富人力和資金，就不要那麼大的排場。
20 樓 hulei1982 2012-04-12 10:52
贊同8樓說的第3點，開發人員對於沒有技術含量的重複性工作是不會認真完成的。
不管是QA還是TE在不同的公司工作職責不一樣，這個不糾結。
目前在我們公司是開發經常加班，測試從不加班，開來測試也要揹負點責任才行。
19 樓 Gorehowl 2012-04-12 10:49
我只要求我的經理懂開發就滿足~
18 樓 oaklet 2012-04-12 10:21
17 樓 沒頭腦 2012-04-12 09:33
16 樓 ronnin 2012-04-12 09:29
2. Dev配備測試祕書，協同dev對測試工作和軟件質量負責。
這個祕書會開發，起碼會寫單元測試代碼，製作測試數據（比如SQL）等
測試類型可以包括大部分：單元測試、功能測試、迴歸測試, 甚至包括性能測試和Soak Test.
3. 規模比較大的團隊或產品，也需要一個QA保障最終產品質量，做集成測試，與運營部、市場部等協調。
12 樓 脣角輕揚 2012-04-11 16:55
+1
11 樓 cgd123 2012-04-11 15:53
10 樓 neptune 2012-04-11 15:50
9 樓 nemohq 2012-04-11 15:32
8 樓 nemohq 2012-04-11 15:29
樓主說的有點像Scrum裏邊的理想情況了，不區分開發和測試的職責，大家一起保證產品的質量。
同意樓主關於QA需要懂技術的觀點，但是其它就有些偏激了：
1. 樓主文章裏的QA團隊可以全部fire掉了，根本就不是專業的測試人員，沒有基本寫test design的能力，沒有責任心。而且樓主說的都是手工的QA，還有很多做白盒測試和自動化測試的QA，樓主不能以偏概全。至少我知道的一個測試團隊他們可以幫助開發找到memory leak，並且給出fix的solution，開發人員經常需要測試團隊的幫助來搭建單元測試的框架，代碼checkin時的自動化測試環境等。
2. 樓主把開發人員說的好像很完美一樣，如果仿照樓主這個說法，可以寫個文章叫“我們需要專職的Dev嗎？”。一個技術強點的QA，有測試的經驗，寫出來的代碼質量比專職的開發好的多。
3. 樓主說的這種理想的軟件工程師基本上是很少，甚至是不存在的。試問哪個開發可以耐下心去一點點的做功能測試？ 即使是寫自動化測試的腳本，對於這些眼高於頂的開發人員來說就是沒有技術含量的東西，有多少人可以認認真真的完成？結果的分析呢？對他們來說這個就是浪費時間，有時間還不如去學下cloud，mobile這些現在熱門的技術，甚至有很多開發fix完defect後，沒進行完全的確認就丟到測試團隊，來來回回讓測試團隊重做很多次的也有。
總之，術業有專攻，開發人員有自己的侷限：太專注單獨的功能點實現，太專注技術，對客戶需求不清楚，對測試的技術和策略沒有了解。 測試也有自己的侷限：對代碼瞭解不夠，對技術不敏感。
7 樓 icefishc 2012-04-11 14:32
6 樓 _mjhx 2012-04-11 14:31
5 樓 aninfeel 2012-04-11 13:51
我們公司的測試部門也這麼幹——原因嗎？比較容易找到bug，而找的bug越多，績效越高。
4 樓 oxware 2012-04-11 13:50
最關鍵的是，測試團隊的頭頭和開發是完全獨立的，直接對總經理負責，任何開發團隊都推卸不了責任。當然負的責任也更大，線上如果出了事故首先也要追究測試的責任