Test Case 分級與管理

這篇算是一種策略，可以解決下面三個問題 :
1. 拿到測試需求時，什麼 test case 要先測?
2. 回歸測試時，什麼 test case 要先測?
3. 自動化測試，什麼 test case 要先寫?

首先看以下這些參考資料 :
1. 測試案例如何區分 RAT, FAST, TOFT ?
2. Release Acceptance Test（RAT）
3. Functional Acceptance Simple Test ( FAST )
再來就是，思考這些 priority 的角度必須從整個系統而非單個功能

裡頭提到這幾個名詞，用我的方式來解讀就是 :

Release Acceptance Test (RAT) :
不管你測的是什麼，絕對不能壞的功能，這個壞了就整個系統不能用
比喻 : 就像是人的心臟被刺穿或腦袋被砍，這個人直接掛掉

Functional Acceptance Simple Test (FAST) :
一個滿主要的功能，但掛了系統還是能運作
比喻 : 瞎了一隻眼睛、斷了一手或一腳，很不方便但還能活下去

Task-Oriented Function Test (TOFT) & Force-Error Test (FET) & Boundary Test :
功能可以運作但不符合規格
比喻 : 骨折或皮肉傷，好好照護就能恢復

Volume Test & Stress Test :
想不到比喻，幾乎不會測

這幾個的 priority 是 :
RAT > FAST > TOFT = Boundary = FET > Volume = Stress

用 [登入] 來舉例的話 :

RAT : 用 “正確的帳號密碼” 登入
FAST : 第三方登入功能
TOFT : spec 規定密碼必須 “混合英文字母大小寫與數字”
FET : 在沒網路的條件下登入 (app 可能因為沒做 error handle 而 crash)

這要怎麼決定 priority 其實有點自由心證，沒那麼絕對 :
比較像光譜那樣，由深到淺一階一階的，主要就是你認為這對系統傷害多大。哪一階要當成 RAT、FAST、TOFT 其實很看情況，甚至負責同一個產品的不同 QC，都很可能想法不同

上面這些 priority，剛好也是以下這些事情的 priority :

1. 想 test case 時 的 priority
先想 RAT、再來 FAST
再來 TOFT = Boundary = FET

2. 實際拿到 DUT 後開始測的 priority
先測 RAT。RAT 沒過的話，直接退回給 RD
再來 FAST
再來 TOFT = Boundary = FET

3. automation 的 priority
(這邊要提一下 automation 其實有 “維護” 的問題，所以要以 “不常變動又重要的功能” 為優先)
先做 RAT : 正好符合 “不常變動又重要的功能” 的原則
再來 FAST : 符合 “不常變動又重要的功能” 的原則，但比 RAT 又次一等
至於 TOFT、Boundary、FET 很有空再做，之後不好維護、效益也低

這樣做的好處是 :
1. 時間有限的條件下，最有效率 (品質/時間) 的方式
2. 先把 RAT / FAST 測完，剩下就算有錯傷害也有限

另外提幾個思考的誤區，希望之後的人不要踩到 :
1. 我當初新人時期的思考誤區 : 花很多時間想 FET & BT 而忽略了 RAT & FAST，結果上線後 RAT 等級的爆掉，本末倒置
2. 一開始整理 test case 的時候，從 “單個功能” 的角度去思考 priority，結果做了一堆 RAT，但這些 RAT 從系統角度看根本不重要