有之前的學員來問我有關開立測試個案的問題
他提到他們家開發人員強調要用 Gherkin 格式來撰寫
但是他們測試人員要一起開立測試個案
對於那種格式測試人員覺得有點難接受
於是我問了幾個問題
(1) 他們開發人員會將那些 test case 自動化
學員回答: 以前曾經有, 後來就都沒有了, 期待有天會再有
(2) 那他們的 PM 看得懂嗎?
學員回答: 沒有 PM, 就是開發人員的頭就是 PM
(3) 他們為什麼要用 Gherkin 的格式, 有什麼好處
學員回答: RD 覺得格式清晰易懂, 很好管理, 可以直接放在 Confluence 上面. 並且他們覺得這是 BDD.
(4) RD 除了這些 BDD examples 外還有別的 test cases 嗎?
學員回答: 沒有. 這些 BDD examples 就是他們的 test cases
那你們測試人員覺得有什麼問題呢？
a. 有些場景似乎不是很容易用 Gherkin 描述
b. 不容易使用 excel 來記錄
想了一下我說到 Gherkin
a. 其實很容易用 excel 方式呈現啊
b. 其實大多場景也可以用 Given , when , then 表示. given when 都可以記錄測試的 input 和步驟. then 的部分也可以記錄測試的預期結果
但是兩邊角色想法上的差別會是
RD: 列出的 input 種類, 條件很少, 或是 then 的預期檢查狀況很少. 導致 QA 會覺得似乎無法描述所有場景. 那是因為 RD 在開立測試個案的時候想不全, 大都只是看簡單的場景, 導致他們用 Gherkin 寫出來的東西看起來很陽春. 這要做的是訓練 RD 開立測試個案的能力. 而不是去嫌棄他們用Gherkin來描述測試個案不好
另外, QA 因為比較常用 free format 的方式去描述 test case, 不習慣看這種有點程式邏輯味道的 format. 所以要訓練QA 去使用 Gherkin format 去描述大多狀況, 而不是去嫌棄 Gherkin 格式看不懂, 或是不好描述.
那位學員還提到一個場景, 為什麼會想寫在 excel 而不是 Confluence 上面
因為在執行 test case 的時候, QA 會去標示這次他們要執行哪些 test case, 哪些有執行過, 哪些是通過, 哪些是失敗, 並且也會做些統計. 可是這些在 Confluence 上不好表示
我說這就是 RD 和 QA 很大不同之處.
RD 在執行這些 test case 時, 會在心裡默默記住, 哪些執行過哪些沒通過, 但是不見得會做紀錄, 可能是懶惰或是怕麻煩.
QA 會把這些東西給記錄下來, 一方面資訊清楚, 一方面可以統計. 但是這些 RD 都不愛.
另外, 遇到 test case 沒過時, RD 只是把那一行的資料貼出給別人看. 但是 QA 或許會做個執行報告, 說明哪些有過，那些有執行. 這些也是 RD 不會去做的.
所以我建議她去討論的是當 test case 執行時, 如何把執行狀況的資訊給顯示出來, RD 會去如何處理這部分?
我想管理者應該不會都是讓 RD 自由心證, 這樣是很方便很省時間, 但是有跑沒跑就是看他們的良心, 並且你也不容易掌握狀態和進度. 可以詢問管理者會有什麼好方法處理. 但是不用去提 Gherkin 格式不好, Conflunce 不夠用等等
另外，回過頭來, RD 這樣開立 test case, 把他想像成 BDD, 這其實是不正確的
a. BDD 是用來釐清需求的, 他最多就是驗收測試在用. 原先測試會有另外的 test cases
BDD 的 examples 是用來確認需求不清楚之處, 不需要列出所有排列組合要確認的事情, 那是測試階段時才要做的. 可是現在很多團隊就把 BDD examples 當作最終的 test cases
b. BDD 是要用來釐清需求的, 因此 example 重點是要 PM, RD, QA 三者都要看得懂, 用不用 Gherkin 不重要.
如果用了 Gherkin 導致 PM or QA 看不懂, 就失去原先要釐清需求的目的.
有些 RD 之所以會用 Gherkin, 可能只是某種優越感, 或是比較偏程式邏輯的呈現方式
尤其若是沒有要自動化, 硬是寫成 Gherkin 我是覺得沒必要.
從這個故事中, 你可以看到 RD 和 QA 兩邊看重的事情, 思考的角度大大不同 ….
發表迴響