Scrum團隊如何落實自動化測試與持續整合？

Feb. 13 15:25~16:26

問題

朋友的Scrum團隊跑了半年，每個sprint結束所產生的可執行軟體離「潛在可釋出」還有一大段距離（品質不是很好）。團隊開始思考要如何提升品質，讓每個sprint可以交付「潛在可釋出的產品增量」。

團隊從QA部門借調一位測試人員—QA甲，希望借助他的力量提升軟體品質。但是QA甲以往都是用人工手動測試來驗證功能的正確性，並不會撰寫自動化測試案例。因此，QA甲需要等待團隊成員完成user story之後才可以開始測試。但通常user story完成後也接近sprint尾聲，沒剩多少時間讓QA甲去手動測試。

有團隊成員建議，請QA甲在下個sprint測試上個sprint的功能，但是這又引發出其他的問題，例如：

• 程式碼凍結：QA甲要測試上個sprint的功能，就必須要求開發團隊不要修改上個sprint所完成的功能。實務上並不可行，因為下個sprint很有可能就是要基於上個sprint所完成的功能繼續開發，要求程式碼凍結會讓開發流程過於僵硬。
• Done Done：因為上個sprint完成的功能留到下個sprint才驗收，那到底上個sprint做完的功能真的有做完嗎？換句花說，上個sprint的Done不是真的Done，還要經過下個sprint的驗證後才知道是不適真的Done。那如果下個sprint找出上個sprint的bug，又該在何時處理？如此一來，沒完沒了，整個開發時程也不容易掌握。

***

理想狀況

自動化測試與持續整合是軟體開發（不管是否採用敏捷）不可分割的一部分，團隊一開始在撰寫功能之前，就要先把持續整合環境架設好，讓自己的空專案可以在持續整合系統上建構，之後才逐一開發新功能。而每一個新功能，都要有足夠的自動化單元測試、整合測試與驗收測試。

為了達到測試自動化的目的，在Scrum團隊中的QA人員（Scrum團隊成員通稱為開發人員）需要具備撰寫自動化測試案例的能力。如果負責測試的開發人員沒有撰寫自動化測試案例的能力，就要考慮：

• 是否願意學習新技能，並且與開發人員一起緊密合作
• 考慮離開Scrum團隊

Teddy的意思並不是說所有的測試案例都必須要自動化，有些測試案例，例如UX方面的測試，或是自動化成本太高的UAT，或是探索式測試，還是可以用人工的方式來做。但大原則是絕大部分的測試必須要自動化，而身處Scrum團隊的測試人員也必須具備撰寫自動化測試案例的能力。

***

非理想狀況怎麼辦

如果團隊已經跑Scrum一陣子，一開始沒有落實自動化單元測試與持續整合，要怎麼「半路出家」？

假設團隊中沒有任何一個人具備自動化測試與持續整合個觀念，最快的方式就是請人教，或是去上課，把基本的知識在短時間先補齊。

接下來可以在DoD（Definition of Done）中訂定自動化驗收測試的標準，讓往後所開發的功能都有基本的自動化驗收測試。至於之前所開發的功能，可以採用以下兩種方式來補寫自動化測試：

• Bug-driven：當發生bug的時候，先寫一個自動化測試案例來反映這個bug。此時這個測試案例一地會失敗，然後去修改程式碼，直到測試案例通過就知道bug改好了。
• 預算制度：每個sprint投資固定時間去補寫之前的自動化測試案例。

***

測試先行或測試後行？

有些技術能力比較好的團隊，會採用測試先行（test first），也就是測試驅動開發（test-driven development）、行為驅動開發（behavior-driven development）、實例化規格（specification by example）的方式，讓撰寫測試案例成為開發流程中的上游，test code先於production code，以避免測試後行（test last）的缺點—先寫production code，永遠沒有時間寫test code。

Teddy覺得測試先行或是後行都可以，但重點是「測試一定要行」。只要有紀律，養成測試是開發不可分割的一部分，測試先行或測試後行可以依據團隊的能力與專案特性自行調整。

***

友藏內心獨白：自動化才能提高QA的價值。