測試 - 從哲學解釋測試

最近因為看了一本書 Lessons Learned in Software Testing,其中有一堂課說學習哲學的其中一個分支-知識論,它可以幫助測試的工作,於是就開啟了我關注「哲學」的開關,然後就產生了這篇紀錄。

首先來簡單描述一下知識論,知識論要問的是「你如何評斷這個知識是 100% 正確的」

何謂知識

在知識論中是這樣子論述的,知識是一件被相信且經過證實的事實

- 知識既是真的,又被相信是真的,是交集。圖來自於維基百科

知識並不會因為自己相信就等同於真實 就如同你相信這個系統沒有 bug,並不會因為你的相信而沒有 bug 所有不能稱為「知識」的,只能稱之為「可能的觀點」

橋可不可以過?

有一天小明與小華在散步,散步到了橋的入口,小明有去過並且知道過了橋之後,可以看見名山勝水的風景

小明說「這個橋,可以過」

小華卻說「這個橋,不能過」

在他們講話的過程中,有一群人走了過去,很不幸的,然後橋就斷了


 

我們可以在這個事件中得知,知識與信仰是不同的。

而小明的相信,是錯的,因為這個橋就是不安全的,如果要讓「橋是否為安全」這件事情成為一個「知識」,那我們就必須得確認「每一次過橋是安全還是不安全」,實際上也不可能完全的「有效」確認的,原因是人類尚無法「測得」宇宙所有不可見粒子(因子)。

故而信仰(英語:Faith)與相信(英語:Believe)不同,信仰是即使普遍經驗顯示是錯的,但憑著信仰與累積的「特殊經驗」或「個人經驗」等「超自然經驗」,卻「繼續相信」下次會轉變為對的,顯示出「偶發狀況」或一連串持續性地「偶發狀況」。自維基百科

知識與測試

我認為產品的知識,以知識的角度來出發理解會是如下圖,通過 測試行為 來驗證 系統實作 是否符合預期,就可以獲得 產品知識

系統實作:紅色(左邊),產品知識:黃色(交集處的圓圈),測試(預言):藍色(右邊),交集卻不是產品知識的部分定義為:非產品知識

P.S. 我認為,測試這回事是沒有限制的,所以不應該有如圖中的外框限制,但為了方便解釋所以加了外框

但是

在軟體開發的世界中,測試所得出的「產品知識」是會因為 Release 之後讓「系統實作」的不同而導致「產品知識」有「時間性」

意思就是,此時此刻的「產品知識」在下一秒就會因為 Release 而導致變化,所以軟體會有「版本」的差異性,讓每一個「產品知識」有了「版本」的概念,就能夠對齊目前某個版本的產品狀態(雖然仍然不能 100% 確定)

在軟體測試中需要被固定住的「環境因素」非常多,只用圖中的三個名詞其實是不足的,例如:使用者的環境(網路、手機規格、電腦規格等)、資料庫已成載的資料量、伺服器因素(放置位置、雲端還是地端、規格、伺服器系統版本等)、當下伺服器的狀態(CPU 使用率、RAM 使用率、多少人同時在線上等)、程式語言版本等等狀態,都會影響到軟體測試的結果

以下開放舉例

那測試人員該怎麼做?

以橋的那個例子做延伸

測試人員能做的,就是盡自己的職責(廢話w)

在橋搭建起來之前,思考這座橋的相關問題,例如:為何需要搭建這座橋?、沒有這座橋可以用什麼替代方案解決要到對面問題?、我們要用什麼材料做這個橋?、這座橋怎麼樣才算是完成?等等…

  • 為何需要搭建這座橋?-理解蓋這座橋的原因,
  • 沒有這座橋可以用甚麼替代方案解決要到對面的問題?-或許蓋橋不是唯一的解決方案,有可能會有較低成本的方式解決,甚至發現不需要橋也能方便快速地抵達到對面
  • 我們要用什麼材料做這個橋?-這個會決定這座橋的年齡、可乘載人數等等
  • 這座橋怎麼樣才算是完成?-決定這座橋的驗收方式,讓其他蓋這座橋的人也知道 DOD (definition of done)

在橋搭建起來之後,測試人員要做的就是去即將被交付的這座橋,做各種可能的「檢查」,螺絲有沒有鎖好、橋的寬度是否與當初設計相符、橋的路面上有沒有坑洞、橋的旁邊是否有圍牆、圍牆是否堅固等

測試人員在盡責的做完各種「檢查」之後,提出詳細的報告,描述著某一個時刻,橋的各種狀態已經檢查完畢沒有問題,而這樣的檢查結果報告出來之後,團隊成員就會有一定的信心,最後才將這座橋交付出來。

OS:你認為,測試範圍是有限,還是無限的?

以上是我的紀錄,感謝閱讀,歡迎大家一起討論