概念與思辨深度
一個行業的發展似乎總伴隨着更多的概念被塑造出來。拿測試來說，我們有單元測試、集成測試、系統測試、迴歸測試、冒煙測試，等等。我們緣何塑造如此多的概念來“爲難”自己呢？答案可以用我從@李智勇SZ老師那學到的“概念越純粹表示思辨深度越深”這句話加以解釋，而這一切又爲了提高同行間的溝通效率。需要特別指出的是，多個相似但不同的概念想表達的是各自的不同之處，而非共同之處。爲此，如果人家在討論單元測試時，你冒出一句“寫好程序，編譯完，跑一跑，看看寫得對不對，這就是最簡單的UT啊！”就不大合適，因爲這說明你根本沒有理解單元測試的概念（可以讀一下我寫的《明晰單元測試》一文）。如果你再加上一句“靠，都是測試，分那麼清幹什麼？”，那還表明你邏輯不清。
我近期所寫的《對軟件測試團隊“核心價值”的思考》一文引發了一些討論。比如，@朱少民老師（後面簡稱朱老師）指出：“‘（文中所述測試）幫助開發人員提高其開發質量和效率’是軟件測試團隊的價值取向之一，但還不是軟件測試團隊的主要核心價值“。於是我向朱老師請教他所理解的測試核心價值，得到的回覆是“軟件測試最核心的價值還是能夠快速發現問題以提供產品的質量反饋，有能力提供準確的、客觀的、完整的質量評估，並通過缺陷分析、用戶行爲分析等，確定缺陷模式和開發人員不良行爲、習慣等，幫助開發人員預防缺陷（從設計到編程、單元測試，不僅僅是設計）”。
之後我的回覆是，“我們應將QA（Quality Assurance，質量保證）與測試區分開來”，因爲我認爲朱老師將測試的範圍定義得太大了。但朱老師卻幫我指出“我這是地地道道的測試，看來你對QA理解不夠。QA的主要對象是（包括開發、測試）流程，QA人員評審、審計和改進流程，以保證質量。測試的對象是產品，包括階段性半成品。從嚴格意義看，測試就是對軟件產品的質量評估”。
類似與QA和測試相關的討論發生在@左耳朵耗子老師寫了《我們需要專職的QA嗎？》一文之後。這些討論又爲我們帶來了@程序員鄒欣老師寫的《測試QA的角色和分工》，以及@段念-段文韜老師寫的《對《我們需要專職QA嗎？》的迴應》。在本文我想順便談一談以前讀這些文章的看法。
誰對誰錯？
如果讀過我所寫的《軟件開發：個人與團隊是永遠的核心》一文的話，知道我給出了高質高效軟件開發的一個效能模型。從模型所涵蓋的內容來看，其範圍非常廣，包括行爲、能力和方法三大支柱。某種程度上，我們在軟件行業的職場旅程有點象是“盲人摸象”（但我們能溝通），這個摸索的過程與我們從事的軟件細分行業（如互聯網、通訊、銀行）、服務公司（如國企、外企、私企）、工種（如開發、測試）等都有着很直接的關係，所獲得的一種成功經驗很可能在另一種情形下根本行不通。摸索的過程很容易通過現實去理解書本上的東西，這不是壞事，但千萬不要以爲所“眼見的”就是“宇宙真理”，也千萬別放棄自己的獨立思考。
存在爭議並不是壞事，我們之所以爭議，是因爲我們有着不同的成長途徑和思考深度（年齡起着一定的作用）。爭議的焦點不是爲了“你死我活”地相互“拉黑”，而應最大可能地達成共識和完善自我認識。所達成的共識越多就越是知道“象的模樣”，這對所有的從業人員都有意義。正因如此，作爲技術人，我時常會告誡自己“多放下一點自大與自尊去接受別人的想法，這對於自己來說是一種很好的成長途徑。”而且，我對於自己所不熟悉的技術領域更多持敬畏而非否定態度。總的說來，誰對誰錯並非爭論的關鍵，而是我們有哪些想法其實是相通或相同的、如何擺事實講邏輯地讓對方瞭解自己的想法。我希望每一位讀者都能理性對待所碰到的爭議，這算是一個小小的呼籲吧。
QA不包含測試
我認爲引起QA與測試相關的很多爭議出現在我們沒有明晰概念，或者有的概念太泛了容易導致問題。QA這個詞就是一個例子！
質量保證很容易讓人想到與軟件質量相關的方方面面，比如測試、流程、缺陷數據分析等。既然這樣，開發工程師的水平是不是也影響着軟件質量呢？那人員的招聘爲什麼不由QA部門管，而是由HR和開發部門管？這個問題問得是不是很無厘頭？但這個問題也告訴我們，各種部門的職責定義其實並非由其名字表意所定，而是由公司根據組織架構的需要指派的。既然如此，我們在使用這些名詞時，一定要根據職責加以展開，而不能依據名字意思本身，否則很容易因爲不當言語而引發沒有價值的爭議。有些爭議甚至影響到了他人的“飯碗”了，你叫人如何理性？這間接地指出，我們的言語應儘可能嚴謹。
如果QA不是測試，那它是幹什麼的？老實說，我不敢憑空給一個角色定義職責，加上我並不是QA（與測試）方面的專家，在此只能以我曾經服務過的Motorola公司爲例說一說我的大致理解。簡單說來，Motorola的QA是一個與測試部門完全獨立的部門，她關注二大事務，一是缺陷數據分析與缺陷預防，二是流程規範與改善。QA會根據測試與開發兩大部門所產生的缺陷數據進行數據分析（或叫數據挖掘吧），發現各產品的缺陷模型（常犯錯誤、缺陷數趨勢等），通過模型去預測可能潛在的遺留缺陷，以幫助開發部門進行改進（最終作用於流程）。另外，QA會全程參與軟件開發活動以跟蹤公司所制定流程的執行情況。比如，以前我就職的Motorola杭州研發中心通過了TL9000認證，QA必須確保開發活動完全符合TL9000的要求，以免出現資質複審時無法通過的狀況。
讀者請注意，我以Motorola公司爲例去定義QA的職責就一定對嗎？未必！對於就職於一些測試隸屬於QA部門的同仁可能很難接受以上的定義。在這種情況下，我們需要思考的是，這個定義是否有助於我們更方便地溝通？如果定義有助於我們的溝通，則這種定義就是可取的，否則值得商榷。理性思考不能忘！
我們需要QA嗎？
如果問“我們需要測試嗎？”答案很清楚，不是嗎？那公司是依據什麼決定是否需要一個工種的？很簡單，不同的技能！
不少軟件公司需要通過象CMMI、ISO9000系列、TL9000等這樣的質量體系認證，並定期複審。這些質量體系主張“質量源於過程”，因此，一定需要有人爲公司制定相應的開發流程並監督流程在公司的到位實施。流程驅動研發的質量意識是需要培養的，這就離不開象“Quality begins with me”這樣的培訓。缺陷數據通過挖掘能幫助發現其他有價值的東西，這就需要相應的數據建模與分析技能。
不難認同，以上知識與相關技能不能由開發或測試團隊的人去兼顧，因此我們需要獨立的QA部門。
QA部門的作用與重視程度在不同的行業完全不同。平均說來，互聯網行業的產品因爲對質量問題具有更高的容忍度（大多互聯網產品直接上線，有問題可以直接回退），而非象通訊行業那樣得交由象中國移動這樣的運營商去運營，也不存在因質量事故引發的第三方懲罰性費用。另外，互聯網產品的用戶根本不關心產品開發過程是否遵循CMMI等質量體系，這與通訊行業運營商對之可能有要求完全不同。我在《離開通訊業入職互聯網圈的一些感悟》一文中進一步談到了兩個行業的不同。
至此，我希望讀者接受我將QA與測試兩個概念區分開的建議。
一點重申
無論使用何種天花亂綴的技法和理論，探尋測試團隊核心價值時一定要打破測試與開發團隊之間的心理博弈防線，否則沒有成功的可能。以我長期在開發一線的經歷，測試的價值困惑首先源於缺乏開發工程師對之的認可，這是種心理感受問題，不是技術問題。《對軟件測試團隊“核心價值”的思考》雖沒有直接給出核心價值的定義，但給出了探索方向，希望值得我們共同思考。
測試工程師思考從開發工程師的“痛點”尋找突破口，或許能找到出路。當然，要真從開發的“痛點”下手，測試團隊必須有些“刷子”，否則只能遊離在質量與效率的邊緣。
對朱老師所言的回覆
朱老師：軟件測試最核心的價值還是能夠快速發現問題以提供產品的質量反饋，有能力提供準確的、客觀的、完整的質量評估，並通過缺陷分析、用戶行爲分析等，確定缺陷模式和開發人員不良行爲、習慣等，幫助開發人員預防缺陷（從設計到編程、單元測試，不僅僅是設計）。
回覆：這個定義存在將測試與QA混爲一談的問題。如果我是一名測試工程師，看到這樣的定義真的會嚇一跳，要求太高了。我認爲質量度量很容易出現主觀現象，難以做到“1+1=2”這樣的真實。軟件質量度量的目的不是爲了“真實”瞭解軟件的質量狀況，因爲團隊級的質量無法直接度量，度量的目的是爲了幫助開發團隊找到改善點。軟件質量管理應重實踐、輕量化，以幫助工程師改善工作習慣和提升開發環境的效率爲目標。我欣賞朱老師身兼QA與測試雙重身份，但就測試核心價值的探討上，我希望能採納所提出的將QA與測試分開的建議。概念只有清晰了、輕量了，纔不容易引起歧義，也更利於我們達成更多的共識和提高溝通效率。
朱老師：我這是地地道道的測試，看來你對QA理解不夠。QA的主要對象是（包括開發、測試）流程，QA人員評審、審計和改進流程，以保證質量。測試的對象是產品，包括階段性半成品。從嚴格意義看，測試就是對軟件產品的質量評估。
回覆：第一話既講測試又講QA，很容易引起誤解。第二句與第三句的觀點我認同。對於第四句，我的問題是“測試真能評估軟件質量嗎？”
對《我們需要專職的QA嗎？》相關文章的看法
《我們需要專職的QA嗎？》這篇文章的論點是QA，但內容其實談的是測試，文不對題引發沒有必要的爭議屬於情理之中。該文中還是有很多值得我們思考的觀點，其中不足之處後面兩篇文章對之加以反駁了。
《測試QA的角色和分工》一文同樣存在將QA與測試混在一起討論的問題，但其中還是能看出QA與測試的痕跡。比如，其中談到了認證。其對於分工的論述我很欣賞，也闡述了爲什麼需要專職測試人員。
《對《我們需要專職QA嗎？》的迴應》一文明確區別了QA和測試，且只關注於測試的討論。我與段老師有很多共識，雖沒有聽過他的演講，但看過他一些分享主題的PPT，能從開發人員的角度找到共鳴點。注意文中的最後一句話，“測試和開發之間有更多配合，更多相親相愛，把測試當成提高和推動質量的手段，不正應該是測試的方向嗎？”