l

2019年2月13日 星期三

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的價值。

沒有留言:

張貼留言