在規劃測試時, 我們一開始面臨的問題是, 整個開發時程分成哪些階段. 也就是說, 是否要都是要由 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/
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
