我是王泰瑞

啊～久久寫一次，一次寫一大篇 XDD 以前我上課在講敏捷測試或是實際在帶敏捷團隊的時候，常常被問到說，Sprint 這麼短， 一個禮拜或兩個禮拜就結束了，測試跟不上啊！是的，如何用測試確保品質，是很多測試人員進入 scrum 後遇到的常見問題。 我都會用這個當例子，我的師父也是這樣教我的： 假設1. 開發人員每個 Sprint 開發 5 個 PBI。 那麼測試人員在第一個 Sprint 需要測試五個 PBI。 很直覺麻，要確保 DoD 有符合麻。還是有人覺得開發出來的東西不用測試？ 那第二個 Sprint 呢？ 開發人員仍然開發出了五個 PBI，測試人員要測幾個？ 五個嗎？錯！ 應該要測 10 個，因為測試人員需要知道第一個 Sprint 的五個 PBI 有沒有被改壞啊。所以第二個 Sprint，測試人員要測 10 個 PBI。 第三個 Sprint 呢？ 理論上要測15個。 這兩個的關係我們可以做出以下的圖： 可是一個測試人員， 在一個 Sprint 內，肯定沒辦法這樣子測啊，總有個上限吧。於是，我們做了第二個假設： 假設2. 測試人員只有一個，他每個 Sprint 只吃得下 30 個 PBI 的測試。 在假設1, 跟假設2, 的情況下，現在我們的要解決的 問題是：在第七個 Sprint 之後， 測試人員會跟不上開發的腳步。 解法呢？ 我這邊提出一些解法給各位參考： 解法一： 大聲宣佈這種迭代式的開發是不能保證品質的，然後回瀑布式開發。 大家回到瀑布式的開發，抓出測試的時程，其中包括 system integration test 以及 user acceptance test，在這兩個階段都要做回歸測試。這段測試時間的長度，取決於這一次 release 的大小或是產品的複雜程度，通常會建議是半個月到兩個月不等的時間。 這個解法的好處是真的可以確保品質，讓測試人員把關，而且管理者(比如說 PM、主管)， 可以看得到測試時期的數字，比如說測試通過率等等。 壞處當然顯而易見的是，在測試時期會花掉一些時間，導致整個 schedule 往後，實務上的經驗是，通常在前面的計劃以及開發階段花去很多時間，擠壓到測試的時間，導致測試人員的時間壓力非常的大，甚至有可能造成開發部門跟測試部門之間的對立。 解法二： 使用自動化測試 讓測試人員撰寫自動化測試，讓每一個 Sprint 完成