讓咱們區分質量保證與測試

概念與思辨深度

一個行業的發展彷佛總伴隨着更多的概念被塑造出來。拿測試來講，咱們有單元測試、集成測試、系統測試、迴歸測試、冒煙測試，等等。咱們緣何塑造如此多的概念來「爲難」本身呢？答案能夠用我從@李智勇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，能從開發人員的角度找到共鳴點。注意文中的最後一句話，「測試和開發之間有更多配合，更多相親相愛，把測試當成提升和推進質量的手段，不正應該是測試的方向嗎？」