國外知名 IT 企業是如何做測試的？
今天看到一篇文章說「我們不需要專職的測試人員」，參考我們需要專職的QA嗎？
但是我聽說微軟、IBM的測試和開發人員比例是3比1（我這是1比3），國外是如何做軟體測試呢？
「Your mom is our QA」，這是 Facebook Release Engineer Manager 說的。有興趣的話可以自己去看這個視頻：The Facebook Release Process。
其實一家公司具體怎麼做測試，要看不測試犯錯的風險有多高、犯錯的成本有多大、修復的成本有多大。在這方面，web 和 app 顯然是不能放在一起比較的。這不是哪家公司有錢，哪家公司摳門的問題。如果 Windows 安裝過程中出錯了，你能按一下 F5 刷新看看是不是好了，不好的話等幾個小時後回來看 Microsoft 是否修復了再 F5，那 Microsoft 也能夠跟 Amazon 一樣不需要 QA。關鍵問題在於 Microsoft 是做 app 甚至更底層的，犯錯的成本很大因為會失去用戶信任，同時修復成本也很大因為所有二進位代碼要重新部署。Amazon 就沒所謂了，就算有小部分用戶因為短時間內無法購物而損失幾個億，修復後用戶按一下 F5 就能用，而且這部分用戶還很可能繼續使用 Amazon。
Facebook 沒有 QA。所有測試都是自動化進行的，工程師自己有責任去寫測試。如果工程師不寫測試，那就是所謂的「Your mom is our QA」了——有一天你媽打電話給你說她想在 Facebook 上看你的新照片但發現打不開，然後你才知道你把 Facebook Photos 搞壞了。當然 Facebook 不會一下子把有問題的版本推給所有的用戶。一般我們會先推 2% 然後監控數據，如果發現某種錯誤飆升，或者某項用戶指標出現明顯波動，我們就會去找原因和修復方案，對比不同修復方案的成本，然後決定下一步怎麼做。至於那 2% 的新版本，就算你真的碰到了，按一下 F5 很可能下一次你就在 98% 的老版本了，所以一般用戶也不會覺得有什麼問題。那篇文章實在是……只能說作者沒有見過優秀的QA……
微軟（至少是Windows部門）的開發測試人員比例是1:1，有例外情況，比如人員流動之類，或者產品需要，最懸殊的情況不會超過2:1。微軟的測試（SDET）會負責測試用例的開發、執行和測試框架的搭建。我之前所在的team，除了unit test由開發（SDE）來寫之外，其它的測試用例都是SDET的工作，包括functional test、end to end test、stress / load test和performance test，採集code coverage，以及測試過程中所用到的各種相關工具。Windows部門內部（其它部門也有，只是不同的工具而已）有統一的工具來按需求定期執行上述測試，所有的測試用例幾乎都是自動化的，不排除有少量的難以自動化的例子。SDET會在測試執行完之後分析結果，有問題有立即file bug。
至於Google，（至少是Ads部門）開發測試人員比例是10:1。Google的開發（SWE）兼職寫測試用例，而測試（SET）專心做測試工具。測試的範圍和上述的差不多，只是上述的多數工作都由SWE來完成。
這種差異是由於兩家公司的產品線的不同造成的。微軟的產品都是離線的，比如Windows和Office，一旦賣出去就收不回來了，在十幾二十年前還沒有互聯網的時候，軟體的質量只能在銷售之前的就確保。於是微軟需要大量的測試人員來保證產品質量。而Google不同的是，它的多數產品都是在線服務，在線服務（比如Google Search、Youtube之類）基本一周可以更新兩次，在極端情況下見到過某些組天天更新的，這樣即使有bug，也能及時修復。所以Google沒有必要在產品剛發布的時候就有很高的質量，質量可以慢慢提升，於是測試的壓力就不太大。
作為思科的測試工程師，以前也在華為，諾基亞西門子工作過，就樓主的問題說下我了解的公司測試的情況。但首先還是說下那篇文章。作者可能是優秀的開發，但碼得一手好code並不能說明就能作好測試，只從代碼的角度看問題難免有點眼光狹隘。不過我猜想這可能和他平時做的產品有關——測試的重要性和產品對穩定性成熟度要求、面向的客戶群、還有修復成本高低有關。要求越高的軟體，測試越重要，越需要完善的測試部門。
相對來說要求較低的軟體如一些互聯網軟體，瀏覽器，手機app等，這些很多都是簡單測試甚至不測試，只要發布一個版本，然後利用龐大客戶群去發現bug，再做下一個版本，再發布……因為這些軟體有問題一般影響也不大，所以對這部分開發人員來說，他們是最覺得專職QA是不需要的。所謂做不了開發就做測試吧，其實也可以說只會寫代碼的話就去做開發吧。
再來就是大型網站，操作系統之類的，主要處理好性能、穩定和安全性，功能只要能正常工作一般問題也不大。這些可能可以由一些資深的開發來做測試，但他們也不是完全能達到獨立測試的要求，另外時間和精力也是一個問題。
接著是電信，企業級的通信設備，除了性能和穩定外，對軟體功能要求也比較高，因為錯誤的嚴重性和修復的成本可能會很高。更重要的是因為功能，協議，網路環境的紛繁複雜，開發能不能達到專業的測試要求，知識面是一個方面：會網路不見得會HA，會語音不見得懂底層轉發，懂微碼不見得懂網路。
最後是一些特別行業的軟體，如航天航空，醫療和工業控制等，這些一旦出問題造成的可能就是場災難，這些就更需要專業的測試了。
------------------------------------分割線-------------------------------
回到正題，簡單說下公司里的測試。在思科，測試稱為DT(develop testing engineer)，開發則是DE(develop engineer)。從比例上看，我們現在部門DT:DE大概是1:1.5的樣子：開發按功能領域分成6個大組，像network, data plane, infra...測試則是3個功能測試和一個系統測試，還加上一些外包測試人員。 一般在項目開始階段DT就會開始介入，主要工作是了解功能實現和協議規範，並作出sanity test plan。其目的是保證系統基本功能的正常。在測試認為軟體不滿足基本測試要求的情況下，測試是可以拒絕接受開發的版本的。
現在公司在推敏捷模式，DT和DE都坐在一起，基本上一個月一個cycle。測試不用一輪輪的反覆進行，一個月做完一點，然後系統測試那邊就同步的測，以前的regression腳本也會同步的跑。開發現在也被要求在提交功能之前要先完成UT（unit test）並提交report以保證基本功能的OK，同時UT的用例會交給測試來review以確認是否能達到要求。之後DT大概用半個月到一個月的樣子完成手工測試，接著就是寫自動化測試代碼。一般測試的時候發現問題可以直接找DE來看來，有時候也能通過郵件描述下現象，基本能確認是個問題就發bug。而像crash，錯誤列印，內存泄露之類的我們一般都直接發bug了，把相關信息描述清楚即可。做完之後，所有的組都會做demo，介紹下當前完成的功能並演示給遠在美國的老大的老大的老大看…-_-。除了完成產品測試，DT也要解決客戶問題。這些case都是客戶那邊發現的bug，開發和測試會一起來重現並分析，然後測試再負責驗證和完成針對這個問題的自動化腳本。
關於自動化測試，之前在諾西的部門是有專門寫自動化測試的工程師，而思科基本上要求每個DT都要會手動和自動化，除了寫自己的還要porting別人的代碼到新的平台。其實在中國，自動化測試看起要比手動高級，這估計還是由於代碼至上的想法造成的——就如同外面有些公司或人認為開發比測試高級一樣。其實在美國很多大牛都是擅長做手動測試的。
總的來說，公司的測試工作涵蓋從文檔設計，單元測試，可用性測試，功能測試，系統測試，性能測試，回歸測試到用戶問題解決的方方面面。嘛，目的都是一個，提高產品質量。
-----------------------------------------分割線--------------------------------------
我在微軟和亞馬遜上過班。就這兩個公司談談我的經驗。
微軟作為第一家純軟體公司，有非常完整和傳統的開發流程。需求分析、設計、實現、測試、部署、運維每一個階段都有明確分工。途中有Manager, leader, SDE, SDET 等完成。這樣做的好處是各司其職，大家都只需要操心分內的事情。缺點是開發周期較長。
這種工作模式下的測試人員是專職測試，有足夠的精力和動機把測試做得很到位。特例總是找得到，但個人經驗是SDET對產品質量是有明顯的促進作用的。同時SDE和SDET的分工配合，減少了開發者的心理負擔。因為需要操心的任務數量減少了。從人道主義的角度是非常不錯的。
弊端也很明顯，那就是成本。資本家的目的就是收割剩餘價值，因此恨不得讓你把操心所有事都操心完。因為我對股東沒有忠誠度，所以只要允許，我一定會想要SDET在隊伍里的。SDE是矛，SDET是盾，一攻一防，各有所長。
亞馬遜作為新興互聯網公司，沒有那麼久的傳統，大家多少都還有一些摸著石頭過河的感覺。亞馬遜這類的互聯網公司，更傾向於所謂的敏捷開發還有continuous deployment。特點就是從設計一直到部署運維都由個人負責。Agile開發的假設條件之一就是每一個組員都是full stack developer，全程都可以做。這樣做的好處是，開發周期短，bug和新feature可以最快推到prod。缺點是員工的注意力分散。
這種工作模式下，unit/integ test都由搞開發的SDE親自寫。就好比自攻自防一樣。個人經驗是，這種工作方式十分靈活，可以跳過測試直接prod。也可以幾周時間專門做測試。但一個趨勢是SDE潛意識會削減測試的時間，在出事故過後又花過多的時間補測試。另外，我個人的經驗是，摳門到不請SDET的公司，通常也不會慷慨到雇專門的運維。這樣做是可以省成本，但也大大加重了員工的身心負擔。
最後，一些軟體部署周期本來就長（如Photoshop/Visual Studio這樣的桌面商業軟體），長時間不會有用戶反饋。個人認為實踐上不可能不用專職SDET。即使在亞馬遜，一些特定的部門因為產品性質，還是會有專職測試。那樣的產品通常fix bug的成本很高。
因此說白了，專職Test的重要性還是由產品性質和預算成本來決定的。微軟有錢燒，大部分組都有專職test。亞馬遜是出了名的血汗碼農場，別說專職test，連運維都要dev上。國外知名 IT 企業是如何做測試的
看了上面幾位的回答，感覺大家對待專門測試人員的態度真是迥異啊。作為國內互聯網企業測試大軍中的一員，對這個話題不得不說幾句。
第一，我們到底需不需要測試
這個問題，我估計大家應該不會有什麼不同意見吧？軟體產品太容易產生bug了，所以測試必不可少。即使是對專門的測試團隊/人員不屑一顧的同學，估計也會承認測試的必要性吧？
第二，測試由誰來做
這裡有幾個不同的選擇：1.由開發人員自己來做測試 2.由少量的專門的測試人員提供測試基礎設施，由開發人員來實現測試 3.由開發人員來實現unit test等部分測試，由專門的測試人員來完成其他的諸如acceptance test, end to end 測試，performance測試，及其他的測試 4. 開發人員只負責寫code,基本不做測試,由測試人員來負責所有的測試
根據我所了解的情況，上面的幾種選擇，都有或大或小的企業在採用著。
第三，根據什麼來選擇上述的測試方案
說「選擇」，我其實覺得不是很恰當。貌似沒有看見過哪個公司，在發展到了一定規模之後，再去重新選擇一種不同的方案。往往是公司在發展的最初，就確定了測試的實現方案。但是看各個不同公司的現狀，還是有一些規律可循的：
1). 公司的產品
產品面向的客戶(2b or 2c),產品的複雜度(其實跟客戶有關係，2c的就要做到簡單易用，解決部分訴求就夠了；2b的就要做到滿足客戶業務的需求)，產品的發布方式(saas,或者傳統的發布方式)，都會影響測試方案的選擇。
我個人的感覺，2c + saas的企業，最傾向採用方式2。2b + 傳統發布方式的，更傾向用方式3。
2). 公司的財力
這個包括兩個部分：
a). 公司給員工提供的待遇
待遇高，就更容易找到能搞定一切(code, test, deploy, operation)的工程師；待遇底，你能找到寫出不錯代碼的人就不錯了，還期待他能有非常好的測試sense,運維能力？
b). 公司對員工產出的期望
如果公司對員工的產出期望非常高，那麼即使員工的能力很強，估計測試這邊完成的也不會太好。如果你能允許花大價錢找來的工程師，可以精耕細作某一點東西，那麼他應該可能會把開發、測試都做的很好。
好了，基於上面的兩個條件，我們來看看下面幾個公司的可能選擇：
(1).有錢，給員工開的工資高，對產出的期望小；
(2).中度有錢，給員工開的工資不低，對產出的期望小；
(3).中度有錢，給員工開的工資不低，對產出的期望大；
(4).沒錢，給員工開的工資不太高，對產出的期望大。
還有其他組合，不過我覺得現實中存在的基本就上面這4種了。大家可以想想上面各個類型的公司的採用哪個方案最合適。
需要注意一點，員工的工資，如果採用開發人員+測試人員的時候，因為測試人員的工資往往比開發人員低，所以更高的測試人員比例，是可以在實現開發人員工資不錯的同時總體工資水平卻不高的。
第四，員工招聘的現實
1). 即使你給出很高的工資，也不是很容易找到開發/測試樣樣精通的人的；
2). 即使不是全才的開發人員，流動性一般也比較高；全才的員工，流動性更高；
3). 測試人員，相對來說比較容易招，流動性也較低；
第五，測試人員的發展
首先申明一點，我認同只會手工測試的測試人員，是沒有太多前途的。能夠寫代碼(哪怕是簡單的腳本)來加速測試工作，能夠搭建自動化測試框架，能夠使用工具進行專門的測試，是未來測試人員發展的方向。精通業務邏輯，能夠替代客戶來實現acceptance test的員工，也有存在的必要，不過在更換職業的時候，這個群體會比較吃虧。
對於SDET我一直有偏見，覺得這些人只是因為開發技能沒有達到開發人員的標準，不得不來做測試工具的開發。如果這些人不進一步去發展測試技能，滿足於開發一些測試工具，我個人反而覺得沒有太多前途。
很多人覺得測試的工作沒有前途，應該是指的那些只會手工測試的「特殊測試人員」吧？其實你為啥不覺得，只會純粹開發工作的「特殊開發人員」也是沒有前途的呢?
====================原作者居然又跳出來大放厥詞了。你說你定義一個「專職的QA」，有啥意思么？是不是我也可以定義一個"專職的DEV「或者「專職的PM」？這樣的嘩眾取寵的說法有什麼意義么？還牛逼哄哄的說啥別人不懂他的意思
另，原作者覺得quora是原裝，zhihu是山寨，不屑於來這個地方...你能更裝一點么?
我是這篇文章的作者。這裡所有的答案都在討論別的東西，老實說，我挺不喜歡來知乎這個quora的山寨網站的。這裡的好多回答的實在是太一般了。
我的這篇文章被討論了兩三年了。還在討論中。這是一個很好的現象，說明大家在思考。但另一方面，我覺得大多數人的思維是亂的，所以我還是在這裡做出回應，算是幫大家梳理一下吧。這樣大家好繼續討論。
1）有正常閱讀理解和邏輯思考能力的人應該知道：「專職的QA」 和 「軟體測試」 這是兩個件事。如果你能分清這兩個事，那再來討論吧。
2）有正常的邏輯思考的人都應該知道："足夠的測試人員或測試案例" 並不能得出 "好的軟體質量" 。我覺得你應該能夠很清楚的明白什麼是「充分條件」，「必要條件」 ，什麼是 「充要條件」。如果一個事從需求，設計，實現上就爛了，測試是不可能讓軟體質量起死回生的。
3）我在我的文章也說過，測試很重要，正因為測試很重要，所以才不能交給只做測試的人去干。應該交給對軟體產品和用戶真正熟悉的人去測試。
4）為什麼微軟叫SDET而不是QA？Software Development Engineer in Test，SDET中文叫：軟體測試開發工程師。主體還是SDE，做的還是軟體開發，只不過偏測試方面的開發。這個不是專職的測試。Google、Amazon中也有SDET，但是大家都知道，真正能保證軟體質量的還是開發團隊自己。
5）好些人舉了很多自己在外企里工作的案例。我想，你們要清楚的知道一件事：西方國家把中國或印度都當成勞動力國家，所以，他們外包了很多勞動密集型的工作到印度和中國來，好多外國公司最開始進中國的時候都是以「測試外包」的方式進來的。你千萬不要以為你是在做一件很牛B的事，也不要以為測試就是這些公司的成功之道。人家很清楚，他們需要一堆人來跑人肉的測試案例，而中國和印度的勞動力便宜，干勞動密集型的事很適合。
6）你需要很清楚的明白一點，對於任何一個公司，如果「產出性」的人多於「支持性」的人，那麼這個公司是往上走的，如果「支持性」的人多於「產出性」的人，那麼這個公司一定處於下坡路上。所謂「產出性」還是「支持性」，就看你的團隊或是你的部門是「財務中心 Finical Center 」還是一個「成本中心 Cost Center」了。
7）我寫這篇文章的時候，我在Amazon，因為頂在一樓的說到Amazon，那我就說說吧。
7.1） Amazon並不是吝嗇錢的公司，Amazon給一個工程師可以配1台筆記本電腦 + 多台台式機，這幾年，Amazon的招人力度和對研發的投入力度也非常大（但是我就不明白為什麼中國區的辦公室環境比網吧還差）。Amazon很少把中國當成外包。out sourcing 在amazon里的比例很小，這不是amazon入華的目標。（但是Amazon會把一些失敗可能性比較大的創新項目交到中國來做以規避解散團隊的風險，而且經理還有大量的政治，2:7:1的績效考核有時候是拿中國團隊來充1……當然，這是另一個話題了）
7.2）Amazon 喜歡小團隊（Two Pizza Team），最多兩個8個人的團隊。如果你的團隊只有那麼多人，那麼你只有一條路——找一個頂多個的人。1個好的工程師頂10-100個爛的工程師，1個爛的工程師，可以很容易地創造2-10個工作機會。你可以認為是吝嗇，但是比較過人多的團隊，我還是喜歡小而精的團隊。人少事少，人多了就雜，雜了奇葩的事也多。（當然，amazon的跨BU的合作有時候簡直就是一場惡夢，你的需求經常會被別的團隊排到1年以後，當然，這是另外的話題了）
7.3）頂在一樓的人說Amazon的SDE要干所有的事包括運維，是的。這就是為什麼一家賣書的公司做出來了全世界最牛B的雲平台AWS，因為Amazon強大的就是：集成測試 + 自動化部署 + 自動化運維。當你的條件受限人手不夠的時候，你必然不能幹所有的事，但你要去做很多自動化的事情，不管是自動化部署還是自動化運維。然而當你的人多的時候，你必然只會簡單用人來解決問題。（勞動密集型與知識密集型的公司差別就在這裡）
——————————————————————————————————————
P.S. 如果你能夠理解我上述說的這些東西，你就會知道我那篇文章的意思是什麼。如果你不能理解，如果你理解偏了，那麼你自然會覺得我極端。
P.S.S. 有人說，QA是管流程的。QA這個詞來自ISO或CMMi的軟體開發流程，那裡面還有一種角色叫SQA，這才是管流程的。【Update: 2015/7/20】現在微軟的大部分團隊已經沒有專職的Test了。很多團隊連OPS也沒了。Dev擁有了更多的權利，也要擔負更大的責任。每個人即是Dev也是Test也是OPS。
=======================================================================
MS的Test，會在設計的時候和Dev一起參與討論，提出意見；會在開Bug的時候直接貼上代碼，你這裡的代碼應該怎麼改。我們大Tester的目標其實是打臉。。。當然也會有被打的風險。
我是文章中的「Monkey陳曄曄 」
國外的測試我自然不去評價，但我看了大部分的評論，我懷疑是不是大家都沒有做過測試。
首先國外對於測試和質量的理解和國內是完全不同的。所以其實國內現在有很多人根本就不管上下文，開始亂搞概念，什麼測試和開發幾比幾，什麼測試不需要，測試和QA都傻傻分不清楚等等。簡直讓我覺得匪夷所思。
國外本身就沒有像國內那麼多的公司進行惡性競爭，同時也不會像國內現在這樣那麼瘋狂的發布版本。同時相信流程和需求也不至於那麼多變。國外無論學術界還是工業界我都見到過50-70歲左右的測試，人家關注的是所謂的case design，關注的是思想。而職責劃分也很清楚，測試就是測試，QA就是QA，SQA就是SQA，不像國內全部混為一談，還以為自己很高大上。
所以呢，我建議大家，自己都分不清楚概念的不要亂評論，不要誤人子弟。同時討論問題要看清上下文，千萬不要一概而論。不要被那篇文章誤導，我所在的公司也是做軟體的。測試開發比例1:1，項目比較大，產品周期比較長，每一個developer只負責一些很小的component，對整個產品了解不全面，能夠完成自己的功能並且自測一下已經不錯了，QA要了解整個產品，從需求到測試，包括搭建測試環境，寫測試用例和開發自動化測試框架，儘可能的做code review。直至完成測試，QA貫穿整個產品開發過程，充分體現一個核心—控制。能夠控制產品質量，預防風險。
我來單單就測試崗位談談我的看法。（QA的定義在各處有不同，我就不談QA了，只談具體執行測試的人）。
如果我們暫時不考慮測試崗位的現狀（誰在做測試，是專職測試還是開發自己承擔測試，等等），我想測試應該有如下目標：
以更低的操作成本發現更多，更關鍵的質量問題。
由此逆推，得出幾種對測試者背景條件的思路（但是這些條件可能是互相衝突的）：
1. 測試者了解軟體的設計和實現的技術細節，因此可以針對可能的弱點來設計測試用例。
2. 測試者對用戶需求的理解是獨立於設計和開發部門的，因此可以更容易發現開發團隊偏離需求的問題。
3. 測試者能夠利用自動化來降低自己的操作成本。
所以，一般人肉測試策略對1，2，3都做得不好。
在人肉測試策略基礎上增加對項目需求／業務流程的培訓，可能會在2上做得比較好。
高端的專門測試人才可能滿足2，3, 很難達到1，2，3。
直接讓開發承擔測試有1，3的優勢。
理想的專職測試人才同時擁有1，2，3，但是市場上稀有, 且一定會貴。（我記得有一次和Thoughtworks合作項目，在那個項目里測試是BA兼職的。）
居然今天才看到這個問題，我來簡單說下我廠的情況。
我廠是有獨立測試人員的，這些人只做測試。至於他們是否同時做N個項目的測試，這個我不確定（應該是會的），但他們肯定不做開發。
我廠很注重開發流程式控制制，流程式控制制的目的是儘可能地提高交付質量，每個人都要通過強制培訓，最新一次培訓時的反面案例之一，便是前段時間的光大烏龍指事件。這年頭程序交易都是受到監管的，假如你的程序寫錯了，例如某個交易的參數沒有交驗其合理性就發送出去了，你自己賠錢是一碼事，監管部門對你進行罰款，甚至吊銷你一段時間交易牌照，因為你擾亂了市場。這時候你只能吃不了兜著走，基本上Head of Technology就要跑路了。
這個流程細節要求很多，其中之一便是測試人員「不能了解系統的實現細節」，當然，他們必須懂技術，例如內存使用情況不正常，他們也得能告訴我們。他們也必須懂業務，這樣能設計出更符合實際場景的測試用例，像我這種對業務不太明白的人來說，基本沒法去做他們的事情。但我作為一個Power Developer可以把工作完成地很好，而測試人員可以幫我節省了很多精力，這可以看做是一種互補，需要有人用另一個角度來看問題。
所以，這自然必須要有獨立測試人員了，這就跟需要獨立的會計師事務所對你進行審計一樣：你自己能做的再好，我也不放心你，必須別人來做。
通過這種流程式控制制，軟體交付的質量（的期望值）自然會有提高。至於投入產出比如何，或者說項目質量是否達到了足夠的標準，這就是另一回事情了。事實上項目不同，對於測試的力度可以有很大差別。例如一個互聯網項目，隨隨便便丟上去把用戶當測試來使亦無不可。但比如交易軟體出了問題分分鐘幾百萬刀損失，醫療軟體出了問題分分鐘死個把人，火箭發射系統出了問題分分鐘幾億刀血本無歸……
真到了某些時候，專職堆測試人員都不夠，還得上形式化證明。當然這就是另一回事了。不知名IT企業。
傳統的瀑布，或者用接近瀑布流程的迭代開發時，在代碼級別上使用靜態檢查工具，UT框架，workthrough與peer review結合的方式儘可能在coding完成後幹掉多數低級bug。
再一個就是管理好功能需求和功能測試文檔。維護好一致性。這一點是跟SONY學的。SONY用了大量的IBM Rational系列工具和自己內部開發的工具進行產品開發中的生命周期管理。
其它的流程估計大家都差不多。我這裡借鑒SONY的東西多一些。因為一大部分工作是開發商用設備，一旦發布更新固件或系統是很麻煩的事情，所以對bug的容忍程度非常低。在軟體趨向於服務化的領域，軟體開發廠商更傾向於頻繁的發布小規模改動的更新。在這種發布要求下，傳統的測試人員花幾個月來穩定軟體質量的開發模式受到了挑戰。
以微軟為例，幾乎所有的部門都在嘗試不再增加測試人員配給，由開發人員分擔部分測試工作。至於將有限的測試力量分配在何處，也尚未在公司內部有共識，各部門都有自己的嘗試。
另一個重要原因應該是控制開支，雖然沒有公司會承認。
實際上在軟體服務化的趨勢下，非關鍵應用場景的軟體質量的確不需要像盒裝軟體那樣高，因為發生錯誤造成的損失有限，反應迅速的話也能很快恢復。
以上只針對服務性質的軟體，傳統軟體不在討論範圍。
看了前面的回答，我特別想回答一下，不過還是先放對問題的回答：
每一個職責都是不可或缺的，當然也包括QA；但是專職的人是可以不需要的，只是可以不需要，而不是必需不需要。
下面私貨：
大部分回答都從技術層面看待測試，只有一個回答提及了質量方面，但是偏偏是認為測試和質量無關。
而在我的認識中，與質量無關的測試當然沒有存在的價值和意義！
測試首先是一個質量相關部門！而不是一個技術性部門，或者說不是一個單純的技術性部門。
這樣說也許好理解一點：
一個企業存在的理由就是為了盈利，企業中的每個人都要為了盈利服務，為了盈利則必須有產品（與話題測試相關的。。。特例豁免），然後產品質量與盈利當然是相關的，當然前面也有人說了，不同產品的盈利能力和質量的相關度是不同的。
另外，也許是測試這個職位的歷史淵源導致了很多人慣性得把測試定位成一個技術職位，然後不可避免的拿出來各種和開發去比較，特別是和開發比技術，在我看來，這是明顯的方向性錯誤。
回到質量角度，對質量有影響的明顯不僅僅是技術，而且我們會發現可以有很多非技術手段解決質量問題。
再次回到技術角度，很多人特別是技術人會認為提高技術能力是解決質量問題的唯一方法，這句話一說出來，很明顯就能感受到其中的不妥，但太多人沉迷其中無法自拔。
回到公司角度，為了保障產品質量，提高技術能力當然是手段之一，但我們都知道有「邊際效應」的存在，技術牛人薪資是非常高的，所以綜合來看是否綜合採用技術和非技術手段來保障質量性價比更高？
所以，非技術性測試的實際意義和價值出現了。
這也是我選擇的測試路線和策略。
QA不是測試，雖然很多公司當測試用。
QA是用來確保軟體研發和實施的質量控制。
它負責的包括：流程管理、規範性設計和監控、關鍵質量kpi審計、質量問題回溯和流程改進
沒有通用的規則說測試一定要誰做、怎麼做。
產品公司和項目公司測試有很多不同。
1.產品公司測試必須也能夠做到更嚴格和完善
產品大多能將業務收斂在公司內部，主要問題都能控制在公司里，在公司內結束。
並且投放出去之後基本就脫鉤了，沒太大控制力去修正。
2.項目主導的測試很難做到嚴格和完善
大型項目由很多產品構建方案，集成帶來很多不確定問題，專的一產品測試根本搞不定，
項目要實施到現場才算真正落地，現場不規範不確定因素太多。
所以第一手測試很多時候是現場或實施工程師完成。
那些跨度太大問題層次很高的高階測試甚至要落到高級售前諮詢來主導。
不涉及前端交互的系統，自動化測試是絕對趨勢。
人力確實太不可靠，而且系統大些，用例人力覆蓋成本太高。
足夠理解業務，又能寫出完備黑盒用例的測試太稀缺。
能把黑盒測試做好真的是很厲害的人才。
精通業務富於經驗，僅通過猜就設計用例挖出缺陷並猜出可能原因。
但這樣的人可遇不可求，多半也很少會進測試。
--------------------------------------------------------------------------
看完了所有回答再補充下，國外公司有的是這樣，不一定：
1.測試會參與特性、架構評估，在前期就確保可測和如何測，並評估測試工作量，然後結合用例數作為成本和周期估算基礎附加到立項投錢的彙報里。
2.測試研發也會安排很強的人，測試工具鏈的開發和使用會很重視
3.無處不測試：開發/測試/實施都會有測試
個人也是不傾向有太多專職測試，主力靠全棧工程師。
更傾向靠技術和管理大牛合理切割目標，然後研測絕大部分都靠全棧工程師。
少數極專業的測試人員來測集成和系統。
而好的QA其實又可以被好的PM和TL所覆蓋。
做了六年測試，感覺國內的測試之路還很漫長，而且正如 @Wu Wenjun 所說，傳統的測試模式受到了極大的調整，正在逐步轉型。但是那篇文章的觀點實在是。。。感覺那個作者不太明白什麼是QA。
我所在的企業不算出名，我說一下我們是怎麼測試的，以及別的部門是怎麼測試的吧。
- 測試人員裡面，外包的佔了大多數，無論是本公司的外國分公司還是國內的公司。無他，節省成本而已。即便是某些答案說的那些什麼產品周期很長的產品，也都是外包人員最多。如果是國外項目，有些時候會直接從印度請外包人員過去出差。出差住宿的標準嘛，印度的公司都已經安排好了。從測試人員的素質來看，以色列等發達國家的外包人員素質普遍比印度人高一截。
- 自動化測試說起來好聽，做起來基本上跟測試人員無關。無他，招測試人員的時候都不要求會寫程序。試問會寫程序的人會想到去做測試么？公司之前招過來的，有開發背景的測試人員，大多來了之後都不願寫代碼了。所以最後都是以手工測試為主。另外，很多手工測試人員是非常討厭自動化的，有抵制的情緒。一般自動化測試做完之後，都會交給外包人員來使用。
- 基本上無論是敏捷測試還是傳統的瀑布測試，都做得跟瀑布測試差不多，開發人員跟測試基本上是分開的。扯皮的事情不少。其實測試界的理論很多，什麼探索性測試，什麼 Session based testing，但都有一個問題，那就是可操作性很低。而且那報告真的很難拿給上級部門看啊，老闆喜歡看數字啊，我們能怎麼樣。所以 James Bach 所說的那些理論，也就真的是理論而已。況且他老人家說了一套理論之後，實際上並沒有具體的統計數據說明這套方法是不是比傳統的 case based 的測試有效。
- 一般都是 TL 負責分活，下面的人接活，case 都是安排到人頭上的。那些說測試人員不會有盲區的實際上都可以閉嘴了，同樣的 case 你跑了幾百遍之後，基本上連 case 都不會看了，直接跑。人的注意力都是一樣的，跑多了你都不會喜歡跑。
- 測試 review 代碼和設計這回事基本上不算數，大部分測試看不懂代碼更不要說設計了，除了能評論 spec 是否有衝突之外，基本上做不了別的。
- 對測試人員的評價是最難的，你說測試是質量保證的話，那架構師和程序員的功勞算什麼？如果你說測試不是質量保證的話，那測試是幹嘛的。況且，很多時候，產品需要發布速度，而不是質量。
- 測試經理都是做開發出身的，還真沒見過測試出身的，除了印度。
老實說你的標題和題注裡面的內容不是很搭架啊。我同時也評論一下陳浩那文章吧。
首先說一下陳浩這人吧，我只能說他比較偏激，尤其是他說測試一個遊戲的概率（如何測試洗牌程序）的那個文章時，我簡直對他有點無語，連隨機概率的幾個性質（獨立性、均勻分布以及不可預測）都不知道，就開始為了罵測試而罵測試，最後只是測了均勻分布。所以 QA 這文章，你不必太當真，他也不是權威。凡是用這種能不能測出 bug 來說測試重要不重要，然後反駁需不需要專職 QA 的文章都沒啥意義的，因為請不請是成本問題，不是重不重要的問題。一個產品需不需要架構師呢，看的是產品的難度和成本，不是產品重要不重要。你想想他說的那個問題，如果你是老闆的話，你是不是出個幾千塊找個數學系或者專門學數理統計的人給個測試方案更好呢？
其次是，隨著軟體的複雜化和發布流程的簡化，現在對只測功能的測試人員的依賴已經越來越小了。大部分時候這部分人員都是外包或者眾包的。這可以節省很多成本。
為什麼說複雜了之後反倒不需要請正式的測試員工，而必須外包和眾包呢？因為別人成本低，每個 bug 所花費的成本比正式員工低很多。測試用例巨多且複雜的情況下，所謂專業的測試人員根本無法保證發現大部分重要的 bug。具有看代碼能力的測試人員，在一堆外包和眾包的情況下，基本上是廢物，人家幾千人隨便點都可以發現一堆 bug，性價比太高了。
而這個時候需要的更多是測試管理人員，這個基本上開發人員可以兼顧，而且還更好。
第三是，大部分的老闆不是傻逼，他們明白賺錢的地方在哪裡，養什麼人在打仗的時候最有用，他們寧願犧牲測試人員都不會犧牲開發人員。在成本和效率有限的情況下，專職的 QA 可以直接被忽略。尤其是遇到公司狀況不好的情況，QA 完全不能當開發用。
第四是，一般只有多個 vendor 集成的項目才會要專職的 QA。這個跟加工廠的做法差不多了，來料總要檢查一下的嘛，況且別人的庫都是加密或者不公開的，是不是開發人員來檢查都沒太大所謂了，請個便宜測試人員不就更好。
第五是，測試真的等於質量？叫 QA 的做的工作真的就是 Quality Assurance? 業界問這個問題不少。那些測試理論大牛（James Bach 等人）給出的結論是 NO ，他們說測試人員只是提供信息而已，評價信息。既然如此，為啥不讓第三方獨立機構來評價，口碑差了還可以換，不用為了所謂的 N+1的賠償來裁人，而且更加公正。請打手來懲罰開發的質量問題，何必自己出手呢，是不是，專業打手外面一抓一大把。有些答案說的什麼開發測試會出問題的，那是公司框架的問題，可以通過請打手來懲罰的。
第六是，真的，聰明的人很少做測試的，所以導致測試的人普遍智商比較低，老闆們普遍不不喜歡請正式的測試人員。我無意詆毀所有做測試的人，但試想想，你所做的工作一個高中畢業生是不是培訓一兩個月就能做？如果是，就承認自己智商低吧，如果還是認為智商不低就跳槽吧，否則做功能測試幾年，就可以去印度繼續你的測試生涯了。
第七是，看看How Google Tests Software (豆瓣)吧，看完之後你會覺得不知所措的，如果你還是做 QA 的話。我所認識的做測試的牛人，基本上都去做開發了，一方面是因為薪水，另外一方面是測試沒啥挑戰性，而且職業生涯很難規劃，換個產品就基本不知道怎麼測試了。
- 眾包或者外包或者開發自測或者社區來測
- 只留 Technical Leader 來管理
- 工具盡量用開源的
- 隱私和安全等其他領域的測試一般會直接交給某些特殊的開發人員和組織測試，一般都是業界大牛
- 你他媽的聽過人家問需要專職的開發，需要專職的產品經理，需要專職的老闆不？測試就是 tmd 重要都不輪到普通測試人員說話，因為你不需要 make decision，你只是 report。
某業界第一企業，有自己的測試框架，自己的測試語言，自己的強大的集群用來隨時跑回歸。
但是測試一般都是讓中國人和印度人做。做功能測試的看不到源代碼。老外覺得測試很重要，不過測試人員沒那麼重要，特別是黑盒，不需要花那麼多錢讓美國工程師做。
我覺得原作者的觀點沒毛病，如果一個測試人員僅僅負責或者只把關注點放在測試上，那麼他是做不好測試的，越來越多的公司要求測試要懂點開發，懂點設計模式，能夠查個db,好一點的公司乾脆測試開發一個標準來，為什麼呢？就是為了在軟體生命全周期這個緯度去檢測軟體質量，提前暴露風險.
測試行業整體在進步，不信你看，現在還有幾個公司是在開發完成後才讓測試介入項目的呢？要知道前些年這可是標準流程啊！
測試這個工種，特別是黑盒測試以後可能沒有了，消失了，淘汰了，但測試這個工作內容並不會消亡，它僅僅是讓另外一個工種代替了，就像現在沒有洗馬桶這個工種了，但是馬桶被洗這個事，是不是天天還在發生呢？
至於開發測試之爭，誰上誰下，誰攻誰受，在我看來不就是:"我當國家主席你掏糞，都是為人民服務嘛~"
在網易遊戲，是QA，我的同事基本上都是985的，也有小部分清華北大的，也有幾個海歸，今年的實習生竟然還有兩個博士。。
簡單說說我們的工作吧～
我們一小半時間測單，就是玩遊戲的功能測試；
一小半時間做各種測試工具，比如導表檢查、資源變更確認、靜態代碼檢查等等（我們基本都自己寫，很少用現成的QTP神馬的）；
還有一些時間調研下新技術，比如分散式測試、測試數據挖掘之類的。
我覺得我們QA還是滿有技術含量的，基本上每個人都是玩的了遊戲，寫的了代碼，發的了論文的～不是大多數人說的那麼低端的嘛，每次看到別人黑測試都很難受啊，哎
推薦閱讀：
※互聯網分享與版權保護相矛盾嗎？如何協調矛盾呢？
※為什麼 Dropbox 等大型服務使用 Python 作為主要語言，即使它的效率比其他編譯型語言低幾個數量級？
※為什麼香港的 IT 行業平均薪酬較低？
※高級運營和普通運營有哪些區別？
※你電腦上跑著哪些好玩腳本？