我的Scrum新體驗 - 測試策略篇

businessman-working

在規劃測試時, 我們一開始面臨的問題是, 整個開發時程分成哪些階段. 也就是說, 是否要都是要由 iteration 組成呢? 可是我們公司有所謂的 alpha 和 beta 階段, 尤其是 beta 階段, 我們必須把產品交給外面客戶去做測試, 這可能是無法廢除的, 那要怎麼配合呢?


公司內的 SQA (專門負責公司內開發流程的專業人士) 說到我門公司之前曾經有過以下的作法:

1. iterations + alpha + beta

前面都是像一般 agile 的 iteration, 但是因為我們可能沒把握做的很好, 在加上以前品質的負面印象, 所以QA會建議之後還是要有正常的 alpha, beta 測試, 但是時間可能比較不用這麼長.

2. iteration 1 + iteration 2 + iteration 3 + ....

整個專案過程都是由 iteration 所組成, 每個 iteration 時間都很短, 不會超過 1 個月, 完全遵循 Scrum 的作法.

但是事實上, 我們公司目前做不到這樣. 我們是屬於另一種變化型, 也就是所謂的 mini waterfall, 雖然有 iteration, 但是只是把原先 waterfall 中每個階段的時間縮短, 並沒有真正 agile 的效果.

因為我們想嘗試Scrum又怕品質不到位的狀況, 因此我們選擇了方法一.

雖然我們選擇了第一種方法, 可是我們自己也承認無法在短短 2 週的一個 iteration中, 兼顧到所有功能的 iteration, 再加上最後有個 alpha stage, 所以我們一開始採取的策略如下:

每個iteration只測試這次新開發的功能.

可是真正開始執行後, 問題來了: 我們無法準時在每個iteration開發完原本要做的功能, 原因有很多, 但是最後的事實就是沒有東西可以測, 因此在面對現實之下, 我們的策略就改成下面的方法:

1. 測試上個 iteration 未測完的功能
2. 準備這次新的功能的測試

所以就變成了 one iteration behind. 我承認目前真的做不到在同一個iteration中, 原因有很多, 但是事情還是要解決. 我的目標是盡全力讓功能能及早被測試, 讓重要的bug能早點被發現及修復.

目前在 iteration 中, QA 大部分的工作和優先順序如下:

1. 手動執行測試個案去測試上個 iteration 中未測試功能 (如果上個 iteration 未測完)

2. 針對上個 iteration 中的功能, 和 RD 討論如何進行自動化, 跟撰寫測試程式 (如果上個 iteration 未測完)

3. 和 RD 討論功能的內容, 並且一同檢視設計和測試個案

4. 針對這個 iteration 中的功能, 開立新的測試個案

基本上, 先執行完手動測試, 在撰寫自動化測試. 因為要讓RD先知道哪些地方有問題. 並且藉由這個過程, 可能更熟悉受測軟體內部設計, 並了解在執行過程中哪些是屬於重複的部份. 有了這些經驗, 再接著做測試自動化, 會比較抓的到重點.

因為一開始就先寫測試程式, 很可能受測軟體的行為並不是你所想像的那樣, 你會有大量re-work的時間. 或者是受測程式還不穩定, 你會有較長的等待時間. 所以我們這樣做會比較有效率.

在 iteration 的階段, 雖然我們的重點是新功能, 但是為了確保之前測過的功能也work, 我們採取的方式如下:

1. 每次要產生新的build之前, 或是有修改時, RD會執行所有的unit testing, 以確認之前的功能是正確.

2. 每次build產生之後, 會自動驅動QA的BVT測試, 從安裝到基本功能的測試, 都要檢查一遍.

可是等到快接近 alpha 時, 我們的策略便加以修改, 需要加入以下項目:

1. 系統測試: 效能測試(performance testing), 壓力測試....等等. 因為這個項目需要多一點時間作準備, 你需要準備環境, 測試資料, 測試程式等等, 並且這個時候受測程式也比較穩定, 有辦法經的起這樣的測試.

2. 整合測試: 確認多個模組或系統, 組合起來是否運作正確. 因為之前測試user story的功能, 都是比較片段, 使用者在使用時, 不會只是使用單一功能, 一定是混合使用.

3. 回歸測試(Regression testing): 確認之前的功能是否正確, 要再深入一點確認之前正常的功能, 是否依然正常. 這也是為了讓之後alpha可以進行的比較, 所做的準備.

在 alpha 階段, 所做的測試就和傳統的作法一樣. 不同的地方在於:

1. 時間: 時間可能會比較短, 因為前面的時間都留給了 iteration, 所以剩下的時間可能不多

2. 穩定度: 前面測過這麼長的時間, 所以相對穩定度會比傳統 code complete 完後, 要好的太多. 不會有一堆 show stoppers 等著QA

後面一點是好處, 所以我們要克服的是第一點, 這也是為什麼我們在後面的iteration必須要調整測試的工作.


作者:David Ko

作者簡介:David具備Certified Scrum Master以及Certified Scrum Product Owner的認證,也是台灣最早期 Agile 社群(AgileCommunity.tw)發起人之一。 為了推廣Agile知識,還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管,並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。

文章出處:David Ko的學習之旅

原文連結:http://kojenchieh.pixnet.net/blog/post/75409837

圖片出處:http://www.getsaga.com/blog/ifttt-recipes-for-work-productivity/

 


若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
David Ko

David具備Certified Scrum Master以及Certified Scrum Product Owner的認證,也是台灣最早期 Agile 社群(AgileCommunity.tw)發起人之一。 為了推廣Agile知識,還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管,並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。

0 則讀友回應