Scrum and XP from the Trenches - How we do Scrum 
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html


14. 我們怎樣做測試

這是最困難的部份. 我不確認是否它只是Scrum最難的一部份, 還是它在軟體開發中, 通常也是最困難的部份.

在不同組織之間, 測試可能是差異最大的部份. 它依賴你有多少測試人員, 有多少自動化, 哪些型態的系統(只是伺服器+網頁應用程式? 或是)發佈週期的長短, 軟體的關鍵性(blog伺服器 v.s 飛行控制系統)等等

在Scrum中, 我們試過很多如何測試的方法. 我將試著去描述我們曾經做過的方法, 以及目前我們得到的經驗


您可能無法擺脫驗收階段

在理想的Scrum世界, 每次的sprint會產生一個可能可以部署的系統版本. 所以只要部署它就好, 是嗎?

不是

根據我們的經驗, 這通常是不可行的, 都會有很嚴重的錯誤. 如果品質對你來說還有價值的話, 某種手動測試的階段是需要的. 對於不隸屬於團隊的專職測試人員, 他們必需利用Scrum團隊沒有想過, 沒時間做, 或是沒有硬體配備去做的方式去攻擊系統. 測試必須和真正使用者一樣的方式, 來存取系統. 也就是說他們必須手動進行(假設你系統是給人使用).

測試團隊會發現錯誤(bug), Scrum團隊必須要發佈錯誤修復(bug-fix)的版本, 遲早(希望會快一點)你將會為使用者發佈1.0.1的錯誤修復版本, 而不是出問題的1.0.0版本

當我說"驗收測試階段", 我是指整個在做測試, 除錯, 以及重新發佈的階段, 直到有個好到可以做生產版本(production release)為止


縮短驗收測試階段

驗收測試階段帶來很大的痛苦. 它感覺相當地不太敏捷. 雖然我們無法擺脫它, 我們可以(並)盡量減少它. 更具體一點的說, 縮短驗收測試階段所需要時間的量. 我們的作法是:
# 提高Scrum團隊所交付程式碼的品質
# 提高手動測試工作的效率(也就是, 挑選最好的測試人員, 給他們最好的工具. 確保他們所說的很浪費時間的工作, 能夠被自動化)

所以那我們如何提高從Scrum團隊所交付程式碼的品質呢? 嗯, 方法有很多. 這裡有兩個方法是我們發現非常有用的:
# 把測試人員放到Scrum團隊中
# 每個sprint中做較少的工作


下一篇: Scrum and XP的實戰經驗 Ch14(2) http://www.wretch.cc/blog/kojenchieh/15282475
上一篇: Scrum and XP的實戰經驗 Ch13(2) http://www.wretch.cc/blog/kojenchieh/15279867

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()