RAPID SOFTWARE TESTING 好好玩 (一)

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

---

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 WORKS
2. xxxx : PASS
3. xxxx : FAIL
4. ...

不過這時 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 中有哪些更系統化的方式, 來練習上述這些方法呢? 下篇分曉.

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

這是第一天結束同學們把學到的兩件事貼在牆上

MICHAEL 很熱血的在 RAP 探索測試 lol

如果讀書會不再只有讀書

IF STUDY GROUP IS NOT ONLY READING BOOK

一個好像回到小時候, 公園裡, 大樹下人們自然地聚合, 討論者生活裡的大小事, 很多地方事務就在這個過程中得到關照和處理
開放空間科技 - P20

很簡單, 好吃, 新奇又好玩. - 食神

閱讀的材料: 它可以是一本書, 一篇文章, 一段影片等.
讀書會一定要有分享: 讀書會非常重要的是要有討論, 分享, 彼此互動, 交流.
開放, 安全: 可以提出各種想法, 允許不同角度的聲音.

• 一定要把驗收測試自動化嗎? 為什麼?
• 有了 SPEC 為什麼還需要 Living Documentation. Living Document 能吃嗎?

不一定, 看狀況, 開發時測過了, 可以選小 feature 進行.
是的, 可以減少 Regression 時間.
是的, 因為我不想加班 QQ.
是的, 可以重複的執行.
是的, 但不是全部, 要先看 CP 值.

好好吃.
方便跨組織溝通.
容易閱讀.
可以從客戶的角度觀看.
即時地幫助修正 SPEC.
用 Living Document 久了之後, 就沒人理會 SPEC 了.

那些年我們一起搞得回顧會議

Na she nan whoo man e chi gao de RETROSPECTIVE MEETING

要跑得快就一個人跑, 若要跑得遠就一群人跑 - 向前跑
(湯姆與哈克)

風 : 這個 Sprint 有什麼需要改進的地方?
石頭, Dave Jones (海盗王) : 這個 Sprint 遇到了什麼阻礙?
船 : 團隊
引擎 : 這個 Sprint 有什麼做得好的地方?

這是我們遇到的第一個挑戰, 原來 3M 便條紙在白板上面粘不太住啊! 但不管! 身為一個 KKStreamer 這種小事怎麼會難倒我們呢? 結果我們拿了無痕膠帶上了一個 Hotfix.

燈塔 : 這個 Sprint 有什麼需要改進的地方?
Dave Jones (海盗王) : 這個 Sprint 遇到了什麼阻礙?
船 : 團隊
引擎 : 這個 Sprint 有什麼做得好的地方?

首先, 我們跟大家解釋這次 RETROSPECTIVE MEETING 的規則, 並說明白板上面每個圖所代表的意義.

接著, 大家想像自己在團隊中的位置, 並且畫在船上, 從這個過程中, 發現一件很有趣的事, 每個人畫的位置都不一樣, 似乎代表者什麼... 

然後, 大家用五分鐘的時間, 開始把這個 Sprint 有什麼做得好的地方, 遇到了什麼阻礙, 及什麼需要改進的地方, 都寫在 3M 便條紙上面.

接著, 大家開始輪流上台分享, 並分別把便條紙貼在對應的圖上面.

最後, 請大家各自回顧了白板上寫的內容, 並用五分鐘的時間把需要維持, 改善或 TODO 都寫在藍色的便利貼上面, 然後再上台分享, 並把這些便利貼在燈塔上面. 

從另一方面想, 燈塔象徵者引導船前進的方向, 所以把事項都放在燈塔上面, 特別有意義. 最後也整理出了下個 Sprint 的 Action Items. 這是我們第一次改變的 RETROSPECTIVE MEETING.

自從上完 CSM (Certificate Scrum Master) 課程之後, 在這個 Sprint (9/4 - 9/15) 發生了好多事情及改變, 很慶幸身邊有一群想要 Do Something 的夥伴!!! 最後分享一張, 本日最有感的貼貼, 結束這一回合.

Understanding calabash-android do resign apk

瞭解 Calabash-android 是如何辦到 resign apk

Crash !!

Crash !!

Crash !!

calabash-android resign < apk_path >

Android應用使用的 APK 文件就是一個帶簽名信息的 zip 文件, 根據 zip 文件格式規範, 每個文件的最後都必須有一個叫 Central Directory Record 的部分, 這個CDR的最後部分叫「End of Central Directory Record」, 這一部分包含一些元數據, 它的末尾是 zip 文件的注釋. 注釋包含 Comment Length 和 File Comment 兩個欄位. 前者表示注釋的長度, 後者是注釋的內容, 正確修改這一部分不會對 zip 文件造成破壞, 利用這個欄位, 我們可以添加一些自定義數據.

../lib/calabash-android/helpers.rb:112

def resign_apk(app_path)
  Dir.mktmpdir do |tmp_dir|
    log "Resign apk"
    unsigned_path = File.join(tmp_dir, 'unsigned.apk')
    unaligned_path = File.join(tmp_dir, 'unaligned.apk')
    FileUtils.cp(app_path, unsigned_path)
    unsign_apk(unsigned_path)
    sign_apk(unsigned_path, unaligned_path)
    zipalign_apk(unaligned_path, app_path)
  end
end

aapt remove < apk_path > xxxx

jarsigner, ‘-sigfile’, ‘CERT’, ‘-sigalg’, signing_algorithm, ‘-digestalg’, digest_algorithm, ‘-signedjar’, dest_path, ‘-storepass’, password, ‘-keystore’, location, apk_path, keystore_alias

zipalign -f 4 “#{inpath}” “#{outpath}

結論: 沒事別亂用不安全的鑰匙