前些天在網站上看到一篇名為我們需要專職的QA嗎？讓我很讓震驚！
發這篇文章的目的，并不是對原作者的看法表示如何的批評，且說出自己的想法（自認為很中正的看法），希望各位網友能說出你的看法，也希望我能解釋很多開發人員的疑惑。
文章鏈接：我們需要專職的QA嗎？
紫色的文字為引用原文，因為引用文章很長，請見諒
在開始今天的討論之前，先看幾個名詞解釋（參考）：
質量保證（QA）：QA（QUALITY ASSURANCE，中文意思是“品質保證”，通過過程的持續改進來提高產品質量，是軟件成熟度模型（CMMI/ISO）中的一個角色
QA可以對開發的具體技術不了解，但要對CMMI、ISO900等的流程要清楚
軟件配置管理（SCM）：配置管理（Configuration Management，CM）是通過技術或行政手段對軟件產品及其開發過程和生命周期進行控制、規范的一系列措施。配置管理的目標是記錄軟件產品的演化過程（其中涉及到基線的概念），確保軟件開發者在軟件生命周期中各個階段都能得到精確的產品配置；
配置管理包括六大任務：配置標識、版本管理、變更管理、配置審核、狀態報告、發布管理，配置管理的最重要的是版本管理和發布管理；
配置管理往往是配置在質量部統一進行管理，現時還要為測試提供一個測試環境，即我們講的搭測試環境。
軟件測試（Tester）：使用人工或者自動手段來運行或測試某個系統的過程（他是一個驗證的過程），其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別，通俗的說是去驗證兩個方面：是否做了正確的某事，是否正確的做了某事
QA通過對流程（過程）的持續改進來提升產品的最終質量；軟件測試通過技術來保證產品的最終質量；配置管理是對過程產品及軟件生命周期進行管理。
所以，到這里我們就可以看到，其實標題中把測試和QA的概念混為一談，是錯誤的！
“我們都同意，Dev 要懂測試，QA 要懂開發，只不過分工不同，既然你中有我，我中有你，那就不要分彼此了，一起攜手開發測試吧 （另外，我個人覺得不懂開發的測試人員不可能測試得好”）
對于上面的觀點我是認同的。
至于園子中轉載的文章，我不知道作者是誰，既然是分享，那么我們來看一下作者的故事：
我們暫且沿用作者的QA稱謂
“我再說說我最糟糕的 QA 經歷吧，這個公司的 QA 部門只做測試，他們的 leader 覺得所有的 test design 和 test 的過程都不需要 Dev 參與，他們是獨立于 Dev 之外的部門，他們幾乎不關心 Dev 的設計和實現，他們只關心能跑通他們自己設計的 test case。但是去執行 Test Case 的時候，又需要 Dev 的支持，尤其在環境設置，測試工具使用，確認是否是 bug 方面，全都在消耗著 Dev 的資源，最扯的是，他們對任何線上的問題不負責，反正出了問題由 Dev 加班搞定。”
上面的文字包含了很多分享者公司的情況，不知是不是可以猜測如下：
把測試能獨立于開發之外（把需求視若無物）進行，這首先是Tester或Leader認知層面上的一個錯誤（是否作者的理解有誤差暫且不論）；
或者可能從中看出來，分享者的公司中沒有測試總監、測試組長之類的Leader或者他們的資質明顯不足以勝任他們的工作，才會出現前面所說的將測試獨立于開發和其他部門而存在；
我們或者可以從Dev的抱怨中看到，公司的測試人員資質不夠（不懂得基本測試工具的使用，不擅長自我學習、自我突破），過分的依賴本身已有的知識及開發人員的協助；
公司對于需求的管理很粗或者根本沒有管理（或者還是測試人員的理解能力太差，無法理解需求的含義，無法分辨需求與實現之前的差異是否可以定義為Bug），如果有明確的需求管理，則不會出現經常無法確認是否Bug的情況；
我們可以從字里行間，感覺分享者的公司好像是為了測試而測試，要知道測試的目的是為了最終的質量，這一點在整個公司上下的目的都是一致的，任何的工作都不能偏離這個目標而存在
我認為：
公司要做好測試工作保證質量，公司從CEO到普通員工有質量意識很重要，只有從意識上認識到質量的重要性，才能真正的做好質量的管理，沒質量的意識，其他就都是空中樓閣；
同時優秀的測試總監和測試組長是保證測試工作質量的前提 ，相信強將手下少弱兵；
不要認為任何人都能做好測試，基層測試人員的素質很重要（懂開發的測試人員或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的感受，測試人員把預期結果寫成“Every thing is fine”，誰他都受不了！
上面所說到的測試人員存在兩個問題：
①測試用例的基本構成不完成，構成元素過于模糊無法達到準確測試的目的，無法實現測試用例的延續（他人無法看懂你的測試用例）
②測試人員對需求或測試理論理解不夠，導致很多的漏洞或重復測試
但是我要告訴你的是“這和測試沒有什么關系，這所有的一切都只能說明，你們的測試人員很濫，他們的很濫直接影響到了你對整個測試的理解”；
同時，我要講的是是否了解需求與是否做黑盒測試沒有關系，下面是黑盒測試的概念可以參考一下：
黑盒測試：也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。
所以，如果遇到上面的情況，不應該是說對軟件測試失去信心（因為我們需要更好的保證質量），而應該向你的上級反應，我們需要更稱職的測試人員！！！
建議去51Testing上看一看有關軟件測試方面的信息
“在做性能測試的時候，需要 Dev 手把手的教怎么做性能測試，如何找到系統性能極限，如何測試系統的 latency，如何觀察系統的負載（CPU，內存，網絡帶寬，磁盤和網卡I/O，內存換頁……）如何做 Soak Test，如何觀察各個線程的資源使用情況，如何通過配置網絡交換機來模擬各種網絡錯誤，等等，等等。”
這就是我上面說的，測試人員的本身素質太差，無法實現自我學習，自我提升與自我突破的情形
要知道在工作中要用到的東西并不是我們都會的，在這種情況下，我們就要積極主動的去學習，個人認為在有壓力的情況下學習，往往是事半功倍的！
“在項目快要上線前的一周，我又私自查看了一下他們的 Test Result，我看到 5 天的 Soak Test 的內存使用一直往上漲，很明顯的內存泄露，這個情況發生在 2 個月前，但是一直都沒有報告，我只好和我的程序員每天都加班到凌晨，趕在上線前解決了這個問題。但是，QA 部門的同學們就像沒發生什么事似的，依然正常上下班。哎……”
首先要肯定的是測試人員沒有測試好，開發人員沒有開發好，所以誰也不要說誰做得不好。人非圣賢，離孰能無過焉！
出現問題時，先解決問題，而不是先追究責任，在問題解決之后，我們需要討論問題產生的原因，如何避免下次再出現這樣的情況，同時如果可以追溯到相關的責任人，我們要進行一定的處理，但處理不是重點。
出現一些緊急的情況，加班難免，要能扛得住！
“為什么會這樣？我覺得有這么幾點原因（和鄒欣的觀點一樣）
1、給了 QA 全部測試的權力，但是沒有給相應的責任，
2、QA 沒有體會過軟件質量出問題后的痛苦（解決線上問題的壓力），導致 QA 不會主動思考和改進。
3、QA 對 Dev 的開發過程和技術完全不了解，增加了很多 QA 和 Dev 的溝通。
4、QA 對軟件項目的設計和實現要點不了解，導致了很多不有效的測試。”
1、質量部的責任是很重的，一量出現漏測或出現線上事故，質量部是要承擔一半或以上的責任的（但具體的也要看公司的情況，如果沒有系統的管理，這個很難說）
2、軟件出現問題，測試人員是不是要重新測試，甚至有時候要加班加點（至于分享者說的他們測試人員不管什么時候按時下班，這還是歸結到測試人員的素質問題，就無關乎能力了）是常有的事；計算機行業是一個快速發展的行業，不思考不主動學習，你很快就會被淘汰，如果你的公司的測試人員還抱著過去的知識、抑制學習、被動思考，那么你可以讓他回家抱孩子，熱坑頭……
3、測試人員不了解軟件工程或開發語言的情況常有，但有時候我們也需要精通業務的人來進行測試，這個是很重要的！
4、這個涉及到我前面講過的對需求的管理與測試人員對需求的理解，以及對基礎測試理論的缺失
從以上的幾個觀點來看，可以看出來文章的作者對測試人員還是很存在一定的理解偏差的，他的問題主要是把他們公司的測試一些人員當成了整個軟件測試行業！
如果他可以跳出他們公司，去質量管理規范的公司看一看，或許能有極大的改觀，不知道他本身是否認可？
“我越來越覺得軟件開發，真的不需要專職的 QA，更不需要只寫代碼不懂做測試的專職的 Dev”
關于作者的這句話，我不敢完全茍同，我覺得更應該這樣說：
“我越來越覺得需要軟件測試人員，但不需要不專業的測試人員，更不需要只寫代碼不懂做測試的專職的 Dev”
我為什么我不說“我們需要專業的測試人員”而不是說“我們需要懂開發的測試人員”？
專業，包括懂需求、懂開發、懂測試理論的人員，也包括懂業務、懂需求、懂測試理論的測試人員，這兩者都是我們需要的優秀的測試人員！
“1） 開發人員做測試更有效
開發人員本來就要測試自己寫的軟件，如果開發人員不懂測試，或是對測試不專業，那么這就不是一個專業的開發人員。
開發人員了解整個軟件的設計和開發過程，開發人員是最清楚應該怎么測試的，這包括單元測試，功能測試，性能測試，回歸測試，以及 Soak Test 等。
開發人員知道怎么測試是最有效的。開發人員知道所有的 function point，知道 fix 一個 bug 后，哪些測試要做回歸和驗證，哪些不需要。開發人員的技術能力知道怎么才能更好的做測試。
很多開發人員只喜歡寫代碼，不喜歡做測試，或是他們說，開發人員應該關注于開發，而不是測試。這個思路相當的錯誤。開發人員最應該關注的是軟件質量，需要證明自己的開發成果的質量。開發人員如果都不知道怎么做測試，這個開發人員就是一個不合格的開發人員。
另外，我始終不明白，為什么不做開發的 QA 會比 Dev 在測試上更專業？ 這一點都說不通啊。”
聞道有先后，術業有專攻！
首先我對寫下這段文字的Dev表示我的景仰，你能說出這番話說明你還是對軟件測試、對軟件質量、對Dev本身的測試還是有一定的了解和意識的。
但是，要知道軟件測試也是一個系統的過程，和軟件開發一樣，他有一個長期的過程，開發人員通經系統、完善的培訓或者可以成為一個優秀的測試人員，這個不虛假；但是術業有專攻，開發人員專攻的是開發，測試人員專攻的是測試（最最好是彼此都有一些了解）。開發人員要進行的測試是對基礎功能的粗略測試，因為他有更重要的開發工作要去完成，做不到詳細的完全測試；而測試人員一方面要詳細的對基礎功能進行測試，還要對很多很多的細支末節進行測試，尤其是平常經常使用的或可能會出現，但一般人很少想到的，在測試中我們稱之為場景，測試人員要對各種可能出現的場景進行測試，往往這種測試是很煩瑣的。
同時，專業的測試人員和專業的開發人員一樣，都是要經常系統、完善的培訓才能正式以一名合格的測試人員的身份上崗的，所以說，不能單純的去懷疑Tester對測試的專業性……
“2）減少溝通，扯皮，和推諉
想想下面的這些情況你是否似曾相識？
QA 做的測試計劃，測試案例設計，測試結果，總是需要 Dev 來評審和檢查。（不是說測試需要依賴開發，這是本身的一個溝通、交流，是保證質量的一個流程需要，在CMMI\ISO中是有明文的規定的）
QA 在做測試的過程中，總是需要 Dev 對其測試的環境，配置，過程做指導。（這個是為了保證測試的正確性，要是因為配置不正確而導致誤報，當如何？）
QA 總是會和 Dev 爭吵某個問題是不是 BUG，爭吵要不要解決。（是不是缺陷需要相互溝通，需要判斷優先級，需要參考需求，需要領導定奪，而不是開發和測試的吵，凡事要有依據）
無論發現什么樣的問題，總是 Dev 去解決，QA 從不 fix 問題。（Tester fix Bug？部分的缺陷是可以，如果他有開發的經驗，但你會放心么？項目經理能放心么，術業有專攻）
我們總是能聽到，線上發生問題的時候，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 的，那只是碼農，不能稱之為工程師。”
這段的理解，說明文章作者對開發者自測還是有比較深的理解，比較重視的！
一個優秀的程序員，不，應該是工程師，要知道的、要做的還是很多的！
“關于 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% 的用戶可以訪問得到，這樣不會因為出問題讓全部用戶受到影響。做這種測試的人必然是開發人員。”
UAT是用戶會要求進行的，如果不做接收測試，客戶不滿意你的項目，后期的款項如何收回？
Beta測試一方面是通過線上的真實情況，檢查程序的功能、性能，同時也是對市場的試探、對用戶的試探，觀察市場、用戶對產品的響應，為公司的后期決策做以參考。
寫在結尾：
對于你的耐心，Tester Chen很感謝，成文時間倉促，如有不妥，希望留下你寶貴的意見、建議。