評《我們需要專職的QA嗎?》的部分觀點

　　左耳朵耗子的文章《我們下需要專職的QA嗎?》，還是引起了各種風波。 就我個人來講，我非常贊同他的抱怨。注意是抱怨，并非是觀點。就觀點來講，其實真的是婆說婆有理，公說公有理。就目前IT行業來講，還真說不清楚。就他的抱怨來講，就國內來講。是的，的確，很多公司都存在他說的這樣的情況。甚至更甚。我自己從一家小公司做起，自己深有體會。在這里，我可以很負責的說，如果之前的一家公司不是因為我的存在，那么左耳朵耗子幾乎說的所有現象都會存在。

　　不過這里我要說一點的是，測試們，不要說別人看不起測試。我曾經在weibo上面就寫到過，中國的測試之所以被別人看不起，根本就是因為測試自己在看不起自己。

　　由于文章太長，我就逐個進行評論自己的看法了。

　　我有一次私自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，只能從需求和表面上做黑盒。

　　Monkey：前半段，我不想評論什么。我只能說寫這種test case的tester太過膚淺，用我話來講，根本就還不如那些實習了一個月的tester。當然，在我以前公司也發生過這類情況。不過這類情況一般都是發生在第一次做測試的人的身上。至于左耳朵公司怎么會出現這樣的人，我個人比較匪夷所思。關于后半段，其實作為一個測試，幾個case測試一個point這個在現實生活中沒有辦法避免的。不知道開發和設計細節，我只能認為是一種溝通上面的不當，測試應當就在設計的時候參與到項目中，并且很是很好的去design case。就如左耳朵說的，并非只是單純的看著文檔，跑著黑盒。不過這里有一點我必須要說的是，測試真正需要的是一個有好的想法，好的設計case的思路，以及很好的用戶體驗的這樣一個人。因為在我看來，黑盒和白盒只不過是方式不同，其主要還在于case本身。

　　1)

　　開發人員做測試

　　Monkey：關于這點，我作為一個測試，不可否認。是的，在很多場景或者很多需求上面開發人員做測試的確相比測試人員更加有效。國內的測試普遍代碼基礎較差，有很多幾乎就沒有代碼基礎。對于這樣的局面，比如我們寫某個api的功能測試，又或者寫一個查看對象生命周期的測試，這類我敢打賭來講，就一個項目的dev來講肯定比該項目的QA寫來的得心應手。

　　但是僅僅限于一些基本功能的保證。dev無法保證一個系統性的全面測試，就如我上一段說了，我不care是dev或者QA去做測試，而是設計case這樣一個人是不是真的想法全面，是不是真的設計的好，是否真的會從一個用戶的角度去設計。左耳朵所說的，QA要懂代碼，這點我不得不說，我很贊同。并非要讓 QA去品嘗自己做出來的產品失敗 或者有bug是什么滋味。而是只有懂的了，才能夠真正的從邏輯上面去分析測試路徑，分析測試方向。這樣才不會讓別人感覺到只是片面的黑盒測試罷了。

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

　　Monkey：就剛剛進入測試行業的人來講，肯定會反駁。但是左耳朵說的也并不完全對，不會做開發的QA只不過不能成為優秀的QA，但是和做測試的Dev沒有可比性其實。

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

　　Monkey：其實就這點，所有公司任何一個測試team和dev team都有出現左耳朵說的現象。怎么說呢，其實dev本身不是只為了coding，QA本身不是只為了測試求測試。如大家真心都是為了把產品做好，各種扯皮，抱怨都會減少。其實基本上來說，國內很多測試和dev的素質(不是說做人的素質)就職業的素養來講還是不夠高。這個是一方面，另外一方面來講，好的流程一種好的溝通方式也可以大大減少左耳朵說的這類問題。原本我是想建議說可能以后可以有一種職位就是開發和測試并存的。但是后來想想，不對。我還是不贊同兩者混淆起來做。兩者除了思維相差太大之外，其花精力以及方向都是不一樣的。不可能讓同一個人或者同一個team去完成。

　　3)吃自己的狗食

　　Monkey：這點我無條件的完全同意，并且非常同意。

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

　　Monkey：我以前認識MS里面的SDET。比例在微軟里面還是蠻多的。我同意不懂開發的人成為不了真正意義上面優秀的測試。但是并非一定要讓懂開發的測試去做開發?；蛘哒f兩者兼做。

　　我不說什么開發是創造，測試是破壞這種理論大話了。我來說實際的，實際上面，測試是一種全面性的工作，雖然任何一個測試不可能讓產品沒有bug。但是也需要無限接近于這個目標。一個人的精力是有限的，我們需要測試是因為一個真正意義上面優秀的測試人員肯定比一個真正意義上面優秀的開發人員想的更多(并非更全)。

　　我一直認為測試的思維是第一，其余所有的只不過是測試實施的手段不同罷了。但是就測試而言，黑盒測試用例的設計，白盒測試框架的搭建，架構，api的封裝。包括各種壓力測試，回歸測試，性能測試，用戶體驗測試，更甚的有單元測試，coverage測試等等。這一系列要在一個項目中做好并非是容易的事情。往往測試會用各種不同的方法去達到一個目的，這個就如同測試會有N條測試用例去覆蓋一個功能點一樣。這個從 dev或者旁人的角度來看的確可能是一件荒唐的事情，但是測試往往是一種摸索，是一種創新，是一種比較的過程。這樣在日積月累之后，case會被精簡，方法會被改進，效率會被改進，bug也會相應的減少，上線之后的問題也會逐步減少。當然一個真正好的測試應該告訴dev，某些類應該怎么寫，某些方法應該怎么寫，某些邏輯應該怎么做保護。dev和QA相輔相成才能夠各取所需，一起提高，不是么?

原文轉自：http://www.anti-gravitydesign.com