我們需要專職的QA嗎？

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

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

1. 其是很多公司成立的專門做測試的技術人員，僅測試不開發。
2. 這些 QA 對于軟件開發技術并不熟悉，甚至不懂。

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

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

兩篇文章

一篇是  “On testers and testing”(中文翻譯)，本文的作者 Sriram Krishnan 是一名程序員，曾在 Yahoo 和微軟工作過，開發過很多軟件，曾被紐約時報報道，寫過一本書，本文是他的一篇博客。他在文章中表達了這幾個觀點——

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

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

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

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

我的故事

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

我有一次私自 review 他們的 test case 的時候，發現很多的 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。另外，我不知道他們為什么那么熱衷于設計一堆各式各樣的 Negative Test Case，而有很多 Positive 的 Test Case 沒有覆蓋到。為什么呢，因為他們不知道開發和設計的細節，所以沒有辦法設計出 Effective 的 Test Case，只能從需求和表面上做黑盒。

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

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

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

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

1. 給了 QA 全部測試的權力，但是沒有給相應的責任，
2. QA 沒有體會過軟件質量出問題后的痛苦（解決線上問題的壓力），導致 QA 不會主動思考和改進。
3. QA 對 Dev 的開發過程和技術完全不了解，增加了很多 QA 和 Dev 的溝通。
4. QA 對軟件項目的設計和實現要點不了解，導致了很多不有效的測試。

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

我的觀點

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

• 充分授權和信任（Empower team members）
• 各司其職，對項目共同負責（Establish clear accountability and shared responsibility）

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

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

1） 開發人員做測試更有效

• 開發人員本來就要測試自己寫的軟件，如果開發人員不懂測試，或是對測試不專業，那么這就不是一個專業的開發人員。
• 開發人員了解整個軟件的設計和開發過程，開發人員是最清楚應該怎么測試的，這包括單元測試，功能測試，性能測試，回歸測試，以及 Soak Test 等。
• 開發人員知道怎么測試是最有效的。開發人員知道所有的 function point，知道 fix 一個 bug 后，哪些測試要做回歸和驗證，哪些不需要。開發人員的技術能力知道怎么才能更好的做測試。

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

另外，我始終不明白，為什么不做開發的 QA 會比 Dev 在測試上更專業？ 這一點都說不通啊。

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

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

• QA 做的測試計劃，測試案例設計，測試結果，總是需要 Dev 來評審和檢查。
• QA 在做測試的過程中，總是需要 Dev 對其測試的環境，配置，過程做指導。
• QA 總是會和 Dev 爭吵某個問題是不是 BUG，爭吵要不要解決。
• 無論發現什么樣的問題，總是 Dev 去解決，QA 從不 fix 問題。
• 我們總是能聽到，線上發生問題的時候，Dev 的抱怨 QA 這樣的問題居然沒測出來，
• QA 也總會抱怨 Dev 代碼太差，一點也不懂測試，沒怎么測就給 hand over 給 QA 了。
• QA 總是會 push Dev，這個 bug 再不 fix，你就影響我的進度了。
• 等等，等等。

如果沒有 QA，那么就沒有這么多事了，DEV 自己的干出來的問題，自己處理，沒什么好扯皮的。

而一方面，QA 說 Dev 不懂測試，另一方面 Dev 說 QA 不懂技術，而我們還要讓他們隔離開來，各干各的，這一點都不利于把 Dev 和 QA 的代溝給填平了。要讓 Dev 理解 QA，讓 QA 理解 Dev，減少公說公有理，婆說婆有理的只站在自己立場上的溝通，只有一個方法，那就是讓 Dev 來做測試，讓 QA 來做開發。這樣一樣，大家都是程序員了。

3）吃自己的狗食

真的優秀的開發團隊都是要吃自己狗食的。這句話的意思是——如果你不能切身體會到自己干的爛事，自己的痛苦，你就不會有想要去改進的動機。沒有痛苦，就不會真正地去思考，沒有真正的思考，就沒有真正的進步。

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

• 只有了解了測試的難度，你才明白怎么寫出可測試的軟件，怎么去做測試的自動化和測試系統。
• 只有自己真正去運維自己的系統，你才知道怎么在程序里寫日志，做監控，做統計……
• 只有自己去使用自己的系統，你才明白用戶的反饋，用戶的想法，和用戶的需求。

所以，真正的工程師是能真正明白軟件開發不單單只是 coding，還更要明白整個軟件工程。只明白或是只喜歡 coding 的，那只是碼農，不能稱之為工程師。

4）其它問題

• 關于 SDET。全稱是 Software Development Engineer on Test。像微軟，Google， Amazon 都有這樣的職位。但我不知道這樣的職位在微軟和 Google 的比例是多少，在 Amazon 是非常少的。那么像這樣的懂開發的專職測試可以有嗎？我的答案是可以有！但是，我在想，如果一個人懂開發，為什么只讓其專職做測試呢？這樣的程序員分工合理嗎？把程序分成兩等公民有意義嗎？試問有多少懂開發的程序員愿意只做測試開發呢？所以，SDET 在實際的操作中，更多的還是對開發不熟的測試人員。還是哪句話，不懂開發的人是做不好測試的。

• 如果你說 Dev 對測試不專業，不細心，不認真，那么我們同樣也無法保證 QA 的專業，細心和認真。在 Dev 上可能出現的問題，在 QA 也也會一樣出現。而出了問題 QA 不會來加班解決，還是開發人員自己解決。所以，如果 QA 不用來解決問題，那么，QA 怎么可能真正的細心和認真呢？

• 如果你說不要 QA 的話，Dev 人手會不夠。你這樣想一下，如果把你團隊中現有的 QA 全部變成 Dev，然后，大家一起開發，一起測試，親密無間，溝通方便，你會不會覺得這樣會更有效？你有沒有發現，在重大問題上，Dev 可以幫上 QA 的忙，但是 QA 幫不上 Dev 的忙。

• 第三方中立，你會說人總是測不好自己寫的東西，因為有思維定式。沒錯，我同意。但是如果是 Dev 交叉測試呢？你可能會說開發人員會有開發人員的思維定式。那這只能說明開發人員還不成熟，他們還不合格。沒關系，只要吃自己的狗食，痛苦了，就會負責的。

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

• 你可能會說吃狗食就是個笑話，因為如果是我，我把干爛的事，就離職走人了，讓后來去吃我的狗食。這個的確是這樣的，但是想一想，你為什么在一開始讓他把事干爛了？另外，如果你的團隊在設計評審和代碼評審里沒有把好關，讓某人把事給干爛了，那么這個人的離職帶來的問題還是這個團隊來抗，于是整個團隊都在吃自己的狗食，挺公平的。痛苦過一次，你的團隊下次怎么干了，就不敢亂招人了，就不敢隨意評審代碼了，就不敢讓人只做一塊東西了。最終還是沒有逃脫吃狗食的范疇。

• 關于自動化測試。所謂自動化的意思是，這是一個機械的重復勞動，我想讓測試人員思考一下，你是否在干這樣的事？如果你正在干這樣的事，那么，你要思考一下你的價值了。但凡是重復性比較高的機械性的勞動，總有一天都會被機器取代的。

• 關于線上測試。我們都知道，無論自己內測的怎么樣，到了用戶那邊，總是會有一些測試不到的東西。所以，有些公司會整出個 UAT，用戶驗收測試。做產品的公司會叫 Beta 測試。無論怎么樣，你總是要上生產線做測試的。對于互聯網企業來說，生產線上測試有的玩A/B測試，有的玩部分用戶測試，比如，新上線的功能只有 10% 的用戶可以訪問得到，這樣不會因為出問題讓全部用戶受到影響。做這種測試的人必然是開發人員。

好吧，我暫時寫這么多，我會視大家的討論再補充我的觀點的。