介绍：9月份的RST公开课，来自台湾的学员写的一篇课程学习小结，分享给各位。

RAPID SOFTWARE TESTING 好好玩 (一)

測試是一門匠藝 - 海盜派測試分析:MFQ&PPDCS

自己很喜歡這段話, 對我來說測試真是一門匠藝. 也許是 TDD 課程之後吧! 自己開始關注 MICHAEL BOLTON 的 BLOG, 當知道大師要來亞洲傳授 RAPID SOFTWARE TESTING (RST) 時, 自己就很想報名, 也很感謝公司對於軟體測試的支持, 自己才有機會一睹大師的風采.

這次來參與 RST 課程, 自己有很多的收穫及衝擊, 無論是課程開始前的討論, 還是課程當中的練習, 先不談 TEST ORACLE 或是 HEURISTIC, 更多精彩的內容不是文字就能完整敘述的, 所以先寫下一些收穫, 歡迎大家一起來交流.

WHAT IS THE QUALITY?

QUALITY 是什麼? 說實在的這個問題, 自己好像從沒認真去探討過. 難道是 ZERO BUGS 嗎? 那 ZERO BUGS 又代表什麼呢? 又或是老闆簽過了 SIGNATURE CERTIFICATE 就是品質保證了呢? 想了半天都沒有答案, 直到 MICHAEL 大師點出了一個問題 (QUESTION), BUG 是什麼?

BUG IS NOT A PROBLEM, BUG IS A PROBLEM BETWEEN SOME PERSON

BUG 從不是一個問題, 而是某人在乎的事情.

例如: 客戶覺得這個 UI 很好看, 即使工程師們覺得不滿意, 又或是客戶覺得這個 FLOW 很糟糕, 但工程師們覺得很好.

QUALITY IS VALUE TO SOMEONE WHO MATTERS

所以衍生出一個論點, 品質是對於某些人來說有價值的事情.

TESTER DO NOT SAID IT WORKS or PASS

這是我的第一個大衝擊吧! 還記得第一天下午的時候, MICHAEL 大師帶大家測試一個 Triangle 的程式, 並且要每一組都寫 TEST REPORT (測試報告).

程式可以參考: Triangle Test

這個程式很簡單, 只要輸入三角型三邊的值, 就可以得到答案, 例如輸入: 3, 4, 5. 程式會告訴你這是直角三角形. 因此身為測試人員的我, 二話不說就直接跟著大家開始找 “BUG” 啦! 過程就不闡述了, 因為這個程式真的慘不忍睹. 例如輸入: b, b, b. 會告訴你這是不等邊三角形, 輸入: 5, 4, 3. CANVAS 顯示會怪怪的. 更有趣的是, 打開 SOURCE CODE 還會發現隱藏的 FEATURES 呢!

在大家一陣攪和之後, MICHAEL 大師要大家開始回報問題. 輪到我的時候, 當然我也很開心展現自己的專業, 如下回報:

1. xxxx : IT WORKS2. xxxx : PASS3. xxxx : FAIL4. ...

不過這時 MICHAEL 大師打斷我, 你怎麼知道這個是沒有問題? 它真的沒有問題嗎? 你怎麼知道它 FAIL? 或是 PASS? 於是 MICHAEL 大師就在白板上面寫下大大的標語. DO NOT SAID IT WORKS or PASS.

測試人員應注重在 FINDING THE PROBLEM OF THE PROJECT and REPORT PROBLEMS. 因此也呼應到稍早提到的

ARE THERE PROBLEMS THAT THREATEN THE ON-TIME SUCCESSFUL COMPLETION OF THE PROJECT?

換句話說, 測試人員更重要的是能否發現專案中有 RISK 的地方? 或者有什麼因素會影響產品如期完成. 話雖如此, 當下我還是很不認同, 為什麼測試人員不能說 PASS 或是 IT WORKS.

秉持者有疑惑就要解惑的精神, 下課時鼓起勇氣去問了 MICHAEL, 假如測試人員不能說 PASS 或是 IT WORKS, 我們要怎麼跟 MANAGER 及 PO 回報測試結果呢? 難不成要我結構性失業嗎?

MICHAEL 大師是這麼回答, 其實我們並不知道真實覆蓋率的上限 (THE LIMITATION OF THE REAL COVERAGE), 也不敢保證驗證完的 FEATURES 在上線兩三個月後是不是就真的沒問題了? 所以 MICHAEL 大師建議我這麼說:

I DID NOT OBSERVE A PROBLEM

IT APPEARS TO WORK (IT SEEMS TO FULFILL SOME REQUIREMENT TO SOME DEGREE)

老實說當下我還是聽的一頭霧水. 直到隔天 MICHAEL 大師講解了 THE LOGIC OF VERIFICATION 才解了我心頭的結.

THE LOGIC OF VERIFICATION

這是我的第二個衝擊吧! 首先來探討 VERIFY 這個字吧. 字典(CHAMBERS DICTIONARY) 上 VERIFY 的定義:

• to check or confirm the truth or accuracy of something.

• to assert or prove the truth of something.

• law to testify to the truth of something; to support.

字典可以參考: Chambers Dictionary Online: Verify

就定義來看好像哪裡怪怪的, 這件事似乎是建立在某些已經假設是對的事之上. 因此, 我們再來探討有哪些事情是可以被 VERIFY 或是不能被 VERIFY 的呢? 例如:

• We can verify that there IS a bug in the product that matters to some 
  person.

• We cannot verify quality.

我們可以驗證在產品中某些人在乎的 BUG, 但不能驗證品質, 因為品質沒有對或者錯.

VERIFICATION IS ABOUT ESTABLISHING WHETHER SOMETHING IS TURE OR FALSE

也就是說很多時候 VERIFICATION 是建立在某些已經知道是 TRUE or FALSE 之上. 舉個例子吧. 我們要怎麼驗證語言學大師 CHOMSKY 的名句:

COLORLESS GREEN IDEAS SLEEP FURIOUSLY

這句話雖然文法對了, 但整句讀起根本沒有意義, COLORLESS 跟 GREEN 根本是矛盾, SLEEP 跟 FURIOUSLY 也違反了習慣. 再來個例子:

THERE ARE NO BUGS IN THE PRODUCT

沒有人敢保證這件事情, 因為很難證實產品無 BUGS. 在很多行業裡面, 可能會有一些嚴謹的規範, 即使我們證明這些功能都符合了規定, 說 WE VERIFY THE PRODUCT WORKS 或 THE FEATURES IS PASS, 但這件事是很絕對的, 因為真實世界有太多的場景或情境我們很難考慮得周全. 這也是為什麼 MICHAEL 大師建議我換個方式說:

I DID NOT OBSERVE A PROBLEM

IT APPEARS TO WORK (IT SEEMS TO FULFILL SOME REQUIREMENT TO SOME DEGREE)

目前對於產品的認知或理解範圍, 沒有發現問題. 這個驗證似乎滿足了一定程度的需求.

當我們談到 VERIFICATION 時, CHECKING 便是我們很重要的一個手段. 在測試裡面能被工具或者機器驗證的叫做 CHECKING, 其他則是 TESTING.

CHECK HAS PROBLEM => BUG FOUND?
CHECK HAS NO PROBLEM => NO BUG FOUND?

曾經我以為測試全過了, 就可以去泡咖啡了. 當然包含自動化測試 (綠燈). 可是做好了這些驗證, 也不過是我們對於產品本身已知功能的確認, 又或者我們希望它本身就是對的, 換句話說, 這些不過只是 CHECKING 罷了. 因為 CHECKING 是可以被執行的, 可以透過機器驗證, 又或者是一個被教導不需要思考的人來驗證. 舉個例子吧. 當我們看到 JENKINS 一排綠燈, 這意味者產品都沒有問題嗎? 又或是看到一兩個紅燈, 難道不是因為 FLAKY TEST 造成的嗎? 記得在課堂上 MICHAEL 大師也開玩笑說, 有時候我們其實在做 FLAKY CHECKED. 

CHECKING IS OKAY, BUT IT IS MOSTLY FOCUSED ON CONFIRMING WHAT WE KNOW OR HOPE TO BE TURE.

難道自動化測試不重要嗎? 讓我們更精準地來看一下, JAME BACH 和 MICHAEL BOLTON 在 ‘03 年對於 TESTING 及 CHECKING 的 REFINE 吧.

Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.

Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product.

更多解釋可以參考: Testing and Checking Refined or 曉梅老師 BLOG - Checking and Testing 解读

TESTING IS MORE THAN CHECKING

套句前輩說的話, 世界上最難的事是你不知道你不知道的事情, 好像有點饒舌, 簡單說, TESTING 其實是一個學習的過程, 就像是小孩子正在探索這個世界一樣, 很多時候你需要透過探索去發掘目前為止未知的事情. 讓我們來看一張圖吧.

所以 TESTING 是一種透過探索和實驗來了解產品的過程. 包含 QUESTIONING, STUDY, MODELING, OBSERVATION, INTERFACE 等. 透過這些過程才有辦法找出一些 PATTERN 來做成自動化的驗證. 至於在 RST 中有哪些更系統化的方式, 來練習上述這些方法呢? 下篇分曉.

附上一些上課有趣的畫面及連結: