咱們須要專職的QA嗎？ 現代軟件工程講義 9 測試 QA 的角色和分工 對《咱們須要專職QA嗎？》的迴應

轉自:  http://coolshell.cn/articles/6994.html

 

咱們須要專職的QA嗎？

這個文章必然是有爭議的，我在個人微博上討論過不少次了，每次都是頗有爭議的。有不一樣的觀點，有爭論老是一件好事，這樣能夠引起你們的思考。因此，對於個人這篇博文，若是你贊同個人觀點，我會感到高興，若是你會去認真地深刻思考，我也會高興，若是你反對，不要緊，能夠討論。

在此以前，我想說明一下我觀點裏的這個「專職QA」是怎麼定義的。

1. 其是不少公司成立的專門作測試的技術人員，僅測試不開發。
2. 這些QA對於軟件開發技術並不熟悉，甚至不懂。

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

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

兩篇文章

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

大 多數的開發團隊並不須要一個獨立的測試角色。即便要有，那麼全部的開發時間比上全部的測試時間應該 >20:1的。。證據嗎？光看看一些從古至今最成功的軟件開發團隊就知道了。不管是當今的Facebook，仍是30年前最初的NT團隊，不少偉大 的產品都是出自沒有或不多測試人員的團隊。

開發人員應該測試本身的代碼。沒什麼可說的。背後的道理並不重要。這包括單元測試，全覆蓋的自動化測試或手工測試或組合測試。若是你的開發人員不能/不肯意或認爲這「不歸我管」，那你須要更好的程序員。

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

你看，咱們都贊成，Dev要懂測試，QA要懂開發，只不過度工不一樣，既然你中有我，我中有你，那就不要分彼此了，一塊兒攜手開發測試吧。（另外，我我的以爲不懂開發的測試人員不可能測試得好）

—- update—- {

     //本篇文章出來後，網上出現了一些對此討論的文章，我一併更新在這裏
【 《對《咱們須要專職QA嗎？》的迴應》做者：@段念-段文韜 】
【 《關於「咱們須要專職的QA嗎」》做者：@Jacky郭 】
【 《咱們須要專職的QA嗎？（評）》做者：@Monkey陳曄曄 】
【《 《咱們須要專職的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，若是有別的團隊也在用你開發的模塊，那麼，別的團隊也就很天然地在幫你作測試了，並且是最真實的測試。

• 你可能會說吃狗食就是個笑話，由於若是是我，我把事幹爛後，就離職走人了，讓別人去吃個人狗食。 這個在現實中的確會發生，也是很現實的。可是想想，你爲何在一開始讓他把事幹爛了？另外，若是你的團隊在設計評審和代碼評審裏沒有把好關，讓某人把事 給幹爛了，那麼這我的的離職帶來的問題仍是這個團隊來扛，因而整個團隊都在吃本身的狗食，挺公平的。痛苦過一次，你的團隊下次怎麼幹了，就不敢亂招人了， 就不敢隨意評審代碼了，就不敢讓人只作一塊東西了。最終仍是沒有逃脫吃狗食的範疇。

• 關於系統集成測試。所 謂集成測試，就是把多個開發團隊開發的模塊集中起來測試。由於開發人員可能沒法看到全局，不瞭解別個團隊的系統，並且步調不一，因此須要有統管全局的專職 的QA進行統籌規劃並作測試。對這個方面，我並不反對，在實際操做過程當中，好像的確用專職的作集成測試的QA統一調度各團隊的時度更有效一些。不過，這還 是不能讓我中止去思考兩個問題，1) 若是開發人員看不到全局，他能開發出更好的軟件嗎？2）這個全職的作集成測試的QA難道不能是各個團隊的骨幹Dev來組成嗎？3）統一調度這個事，不更像 是Project Manager要作的事嗎？

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

• 關於線上測試。 咱們都知道，不管本身內測的怎麼樣，到了用戶那邊，老是會有一些測試不到的東西。因此，有些公司會整出個UAT，用戶驗收測試。作產品的公司會叫Beta 測試。不管怎麼樣，你老是要上生產線作真正測試的。對於互聯網企業來講，生產線上測試有的在玩A/B測試，有的玩部分用戶測試，好比，新上線的功能只有 10%的用戶能夠訪問獲得，這樣不會由於出問題讓所有用戶受到影響。作這種測試系統的人必然是開發人員。

好吧，我暫時寫這麼多，我會視你們的討論再補充個人觀點的。

—– update  2012/4/11—–

一些人以爲我是在泄私憤，我可以理解爲何我會被這樣誤解，可是沒有關係，不少新東西新觀點老是會被誤解的，我坦然面對。請你們拋開個人這些情感因素，單純的思考一下，沒有專職QA的的團隊架構是否有積極的意義在裏面？

再補充一點，你們思考一下，QA是保證質量的，可是不少QA是在作測試，軟件質量是測試出來的嗎？若是不從需求分析，軟件設計，代碼實現上作好控制，到測試的時候你還怎麼保證質量呢？

（全文完）

歡迎關注CoolShell微信公衆帳號

（轉載本站文章請註明做者和出處 酷 殼 – CoolShell.cn ，請勿用於任何商業用途）

——=== 訪問 酷殼404頁面 尋找遺失兒童。 ===——