一般需求文件, 開發人員都會覺得寫得不是很清楚, 讓他們誤解客戶或是 PM 的意思, 導致開發過程來來回回, 時間和成本都浪費了.
這時候 PM 可能會跳出來說, 我已經寫得很詳細了, 否則你出來寫寫看, 看看在相同時間和壓力下, 你是否能寫得更好.
沒錯有些 PM 是非常努力, 盡可能把他知道或者所有狀況寫出來, 他們已經做出最好表現了. 但是, 文字描述天生上就容易讓人誤解, 並且有很多漏洞, 所以需要有別的方法來幫忙.
例如: 一個登入畫面的功能, 用戶要輸入用戶代碼和密碼.
用戶代碼: 最長 120 個字元, 只能包含文字和數字
密碼: 至少 6 個字元. 包含文字, 數字, 和特殊符號
當輸入錯誤時, 要顯示訊息提示告訴用戶
如果我們再加上以下範例來近一步說明這個需求, 是不是清楚一些
|
個案代碼
|
用戶代碼
|
密碼
|
系統反應
|
註解
|
|
1
|
abc
|
A12345
|
顯示系統數位儀表板頁面
用戶代碼線顯示於右上角
|
|
|
2
|
大衛
|
A12345
|
彈出視窗
顯示: "不合法用戶”
|
不能接受中文
|
|
3
|
ＡＡＡＡ
|
A12345
|
彈出視窗
顯示: "不合法用戶"
|
不能接受全形
|
因為他使用明確 (specific) 的輸入, 以及明確 (specific) 的輸入, 而不是”最長 120 個字元” 這樣有點模糊的句子,
這個表格並不是測試程式碼, 但是等程式寫完之後, 是可以用來驗證開發人員寫的是否正確的. 如果之後有人有空可以將它自動化, 也沒自動化也容易讓測試人員進行手動測試, 因為它就是一堆明確的測試個案.
測試個案 和 需求文件 的差別, 在於測試個案需要有明確的輸入資料, 以及明確的預期結果值, 將來不管誰來執行這些測試個案, 所得到的結果才會相同. 可是需求文件不見得有 specific 的資料值, 因此每個人解讀可能不同, 或者每個人會輸入的資料值會不同, 導致可能會有不同的結果發生.
所以在討論需求時, 利用一些範例 (examples) 來詳加說明需求, 那些範例就變成是測試個案, 這些測試個案將來就用來驗證需求是否被落實. 如下圖所示. 這就是 Spec by Example 想要強調的精神.
至於是不是把把測試個案弄成自動化, 那是後話, 那是錦上添花.
所以不管你需求文件寫的詳不詳細, Spec by example 的精神都是對你幫助的.
全站熱搜
留言列表
