打破測試團隊無用錄的魔咒 2 - 從吸塵器來看怎麼測試規劃
各位都知道 Dyson 他們的吸塵器吧？
標榜「吸力永不減弱的吸塵器」！ 號稱 吸塵器界的 LV ！
除了功能性高外，品質好 也是等同重要的！
從打開他們的型錄 第 1 頁 就可以看到
斗大的「測試！測試！測試！」
並說明為什麼他們家的吸塵器真的很耐用！
「在研發階段，Dyson 的樣品會歷經 550 種的測試……」
「測試按鈕耐用度 20000次…」
「將吸塵器向上提起，並以時速 30 公里重力加速度，將機器往下摔向鐵板…」
「軟管來回拉扯達 7280次 ，相當於 21 年的使用時間 」
對！各位沒看錯！上面講的都是「吸塵器」 XDDD
有發現嗎？？上面的各種測試都是有「數據」的
回到我們軟體來看也是一模一樣的問題！
「每次開發階段 都會經過 500 種 測試 」
「 5000 個線上人數同時登入時，進入首頁於 3 秒 內回應。」
「系統連續輸入 1000000 筆交易的訂單後，記憶體損耗不超過 10 %」
「模擬 20 種方式，查詢 10000000 筆交易歷史資料時，可以於 2 sec 內獲得清單」
以往我們被問到的不也是這些嗎？？
是的！測試沒有自動化工具是不可能的有完整的數據可以回答。
因為我不可能真的自已塞 100 萬筆，然後手動下 100 萬筆的訂單。
也不可能動員 5000 位使用者幫我們測試 ( 連 5 位都生不出來 )
自動化測試 並不是 口號喊一喊就行，必須要經過縝密的規劃才不會做白工。
不要怪工具為什麼不能這樣不能那樣，自動化的前提是要先「錄製」一遍的
上一篇提到 Test Professional 新功能 時有提到「為了解決需求而有對應的測試 」
這正好對應到「在研發階段，Dyson 的樣品會歷經 550 種的測試… 」
從測試角度來看，這 550 種測試就是指 550 個 測試案例 ( Test Case )
每一個 測試案例都可以對應到某一個「需求」or「功能」
開啟我們的 Test Presseional 後
最上面從左至右依序有「計劃」「執行」「追蹤」「重組」
先選擇最上面的「Plan」，因為第一件事就是分類
對應的是需求請直接點選 「Add requriments」
可以直接將 PM 所建立好的 需求 直接拉過來 當做 Test Case 對應的項目
也可以依測試團隊的需要，自行定義 測試的 樹狀結構 ，而 Query-based Suite 則是可以讓 非需求的 workitem 當做 suite 使用
** Requriments 在測試的架構中是可以「重複的」
建置方式沒有限定，請依團隊的測試人數、文化等等…
在此提供依幾個方向給大家參考！
若是人數有限 ( 一人身兼數職 ) 時 ，建議不要搞得太複雜，請全部都以 「需求為主」
因為 PM 只要維護「一份」需求清單就行
若是有專職的 QA 的話！再考慮設計 測試架構！ ( Suite ) 或是 功能架構
OK ！ 接下來 QA 就可以去分析 要做那些測試 才能符合目的
直接建立選「NEW」，若有已經建立好的請選「Add」
還可以進階設定每一個 suite 的 Area 、 反覆項目、起迄時間、測試環境 ( Hyper-V 的整合測試日後會提到 ) 都是在這裡設定
點選 Suite 後， 再選擇左上角的「屬性」即可設定
到目前為止我們已經依 QA 的規劃進行 測試案例的分析 和 分類
搭配之前所提到的「手動」測試 ( 上一篇 ) 後就可以先確認功能是否可以 work
待這個版本上線後，才會著手 自動化測試