軟件測試工程師的角度看論證學問
爭論與論證從來都不是新鮮事物,作為軟件行業(yè)的科技工作者,理應對各種論證的手段了如指掌才是。然而,從各種我參與的有爭論的場合來看,事實并非如此。許多論證最終都停在口號式的結論,或是由于自說自話無法進行下去。科學對人類的貢獻之一在于科學的方法,而“合理”的論證方式才是科學真理得以彰顯的手段。
《論證是一門學問》一書中提到了論證的基本規(guī)則,以及各種論證的方式:類比論證、因果論證、演繹論證。這些方法都不是什么難度很高的方法,但在實際的爭論過程中,尤其是在微博上進行的論證中(字數的限制也是導致誤解的原因之一),卻并不經常被論證的雙方所遵守。
一個觀點包含“前提”和“結論”。前提是為你的結論提供理由的表述。前提一般基于具體的事實或是已經被事實證實的結論,通過前提,借助各種論證的方法就 能推導出結論。這個過程看似簡單,在很多情況下卻并非顯而易見。《論證是一門學問》一書的第3頁給出了《福爾摩斯全集》中的《銀色白額馬》中福爾摩斯的一 個推論過程:
馬廄里養(yǎng)著一條狗,然而,盡管有人進入馬廄并牽走一匹馬,(這條狗)卻沒有叫……顯然,……來者是這條狗相當熟悉的一個人。
在這個推論中,福爾摩斯有兩個前提。一個顯而易見的前提是,狗沒有沖著來人叫;另外,福爾摩斯使用了一個他認為我們都會認可的前提:狗會沖著陌生人叫。這兩個前提合起來,便能夠得出他的結論:來人是狗熟悉的人。
接下來我們用幾個更貼近各位工作實際的例子來展示不合理的推論過程。
例1:
軟件測試工程師懂得開發(fā)后,會從開發(fā)的角度思考問題。這樣測試工程師就不能起到與開發(fā)工程師在思路上互相補充的效果了。
這個推論過程是一個典型的假言三段論(Hypothetical syllogism,見《論證是一門學問》P80),這里的要點是,只有在連續(xù)的兩個推論都都沒有問題的情況下,最后的結論才是有效的。這里的兩個推論分 別是:1,如果軟件測試工程師懂得開發(fā),就會從開發(fā)的角度考慮問題;2,如果測試工程師從開發(fā)的角度考慮問題,就無法起到與開發(fā)工程師在思路上互相補充的 效果。
顯然,對第一個推論,其要害在于,是否一個人懂得了某種思考方式,就一定會應用這種思考方式?答案顯然是否。很容易用反例方法推翻這個推論:成人通常也可以懂得兒童的思維方式,但這并不意味著他一定會用兒童的思維方式去思考問題。實際生活中,大多數父母都能夠在懂得兒童思考問題的同時用成人的思考方式考慮問題。
因此,由于第一個推論就不成立,最終的結論顯然不可靠。
例2:
很多組織甚至認為獨立的測試團隊是不需要的,這種觀點是錯誤的!他們認為測試不重要是因為他們對質量不重視!。
這里的前提有兩個:1,很多組織認為獨立測試團隊是不重要的;2,這些認為獨立測試團隊不重要的組織不重視質量。很顯然,稍微深入一點探討這個結論,就 很容易發(fā)現,“很多”這個前提沒有數據來源,可能僅僅是推論者的一個主觀感覺;另外,由于“很多組織”本身就是一個虛擬出來的概念,更談不上有任何實例來 說明“很多組織”中的這些都是對質量不重視的公司。反而,針對這個論斷,容易舉出好些反例來證明它是不可靠的(大多數互聯網創(chuàng)業(yè)公司都會在很長一段時間內不設置獨立的測試團隊)。
關于例1和例2提到的話題,我并不想在這里進行討論。拿它們做例子,不過是說明一個有效的論證應該是什么樣子的。
論證中,一方面需要為自己的觀點提供可靠的前提,提供合理的邏輯推斷過程,同時也需要對自己不認同的觀點提出置疑和反駁。與眾不同的觀點并不可怕,可怕的是無法以符合邏輯的方式捍衛(wèi)自己的觀點。
當對自己不認同的觀點提出置疑的時候,反例是最簡單的方式。但要舉出反例,必須清楚的了解對方觀點的定義。由于所有觀點就是基于前提(事實)和推理過程的,證明對方的前提的不正確性,或是證明對方的推理過程的不正確性同樣奏效。例如,有以下觀點:
例3:
Google的測試工程師與開發(fā)工程師的比例是1:10,因此只需要少數的測試工程師就能做好測試工作。
這里的前提有三個:第一個是顯而易見的前提,“Google測試工程師與開發(fā)工程師的比例是1:10”;第二個是隱含的“Google的測試工 作做的很好”;第三個前提隱藏得更深,“Google的測試工作完全是由測試工程師來做的”。這三個前提中的任何一個不成立都會導致這個結論不成立。在我 看來,最容易被擊倒的是第三個前提(“Google的測試工作完全是由測試工程師來做的”),實際上,這個在Google內完全不成立。但有趣的是,相當 多的對這個觀點的辯駁都集中在第一個和第二個前提上。
例4:
Google的X項目的工程師共有15名,其中測試工程師4名,因此Google所謂的開發(fā)與測試人員的比例是1:10是不真實的。
很顯然,這個論斷根本就偷換了要反駁的結論。“Google的開發(fā)與測試工程師比例是1:10”并不等于“在所有Google的項目中開發(fā)與測試的比例都是1:10”。因此,要推翻這個前提,其實最簡單的方法是拿到Google的開發(fā)工程師與測試工程師的總人數比例。
例5:
Google的產品經常出現bug,因此Google的測試做的并不好。這些不好都是由于Google的測試工程師太少造成的。
可靠的前提才能建立可靠的結論。說Google的產品經常出現bug,最好拿出相應的數據。這方面James A. Whittaker顯然就老練得多,這哥們在自己blog的為什么要離開google的文章中用了一些他自己的感知數據證明這一點。不過即使這 樣,Whittaker也沒有說“google的測試做的不好”,原因是“好”與“不好”根本就沒有數字上的標準,bug數多少叫做好?bug的影響范圍 (人數)與造成的失效成本要不要計算?這個推論的第二個部分則更是“沖動論證”的典型。它同樣隱含了兩個前提:1,在google中,發(fā)現缺陷是測試工程 師的職責;2,測試工程師數量的多少與產品中遺留缺陷的數量呈負相關。可惜的是,這兩個前提都不能夠成立。
啰嗦了一堆文字,也給出了一些我自己能看到和聽到的不合理的論證,不過,這篇文章的用意并不是想在這些例子涉及到的問題上挑起爭端,而只是希望大家都能夠用更好的論證方式捍衛(wèi)自己的觀點,以及看待別人的觀點。
我經歷過和了解到的中國的學校(大學、中學、小學均如此),大多都不太在意對學生論證能力的培養(yǎng),作為這個體制中被培養(yǎng)出來的一員,我在很長時 間內一直沒有掌握正確的論證方法。但隨著工作中的體驗越來越多,接觸到了越來越多的優(yōu)秀同事,才發(fā)現自己身上缺少的這種論證方法的確會影響到自己的發(fā)展和 工作。鑒于此,我希望通過本文,能夠讓更多的工程師,尤其是測試工程師了解到論證的方法,希望有更多人能從論證中找到棋逢對手的樂趣。
posted on 2012-08-31 09:47 順其自然EVO 閱讀(145) 評論(0) 編輯 收藏 所屬分類: 測試學習專欄