14 . 我們怎樣做測試
這是最困難的部份。我不確定是否它是Scrum中，最難的一部份。還是它在軟體開發中，通常也是最困難的部份。
在不同組織之間，測試可能是差異最大的部份。它依賴你有多少測試人員，有多少自動化，哪些型態的系統(只是伺服器+網頁應用程式？)發佈週期的長短，軟體的關鍵性(blog伺服器 v.s 飛行控制系統)等等。
在Scrum中，我們試過很多如何去測試的方法。我會試著描述我們曾經做過的方法，以及目前我們得到的經驗。
您可能無法擺脫驗收階段
在理想的Scrum世界，每次的Sprint會產生一個可以部署的系統版本。所以只要部署它就好，是嗎？
沒錯！
不是。
嘿？
根據我們的經驗，這通常是不可行的，都會有很嚴重的錯誤。如果品質對你來說還有價值的話，某種手動測試的階段是需要的。
滿口胡言！我不敢相信我會這樣寫！這本書已流傳到各地，並且有很多人唸過和相信它，我真的感到羞愧！好爛的作者，不要再寫這些錯誤的東西了！＊啪啪＊是的，手動測試是非常重要的，並且有些環境是無可避免的。但是，應該是由團隊在 sprint 中進行，而不是交由另一個獨立的團隊來進行，或是保留到未來的測試階段來進行。這不就是為什麼我們會拋棄瀑布式模型的原因嗎？ 還記得吧？
對於不隸屬於團隊的專職測試人員，他們必需利用Scrum團隊，沒有想過、沒時間做、或是沒有硬體配備去做的方式，去攻擊系統。測試必須和真正使用者一樣的方式，來存取系統。也就是說他們必須手動進行(假設你系統是給人使用)。
測試團隊發現錯誤(bug)，Scrum團隊必須要發佈錯誤修復(bug-fix)的版本，遲早(希望會快一點)你將會為使用者發佈1.0.1的錯誤修復版本，而不是出問題的1.0.0版本。
當我說"驗收測試階段"，我是指整個在做測試、除錯、以及重新發佈的階段。直到有個版本，可以好到做生產版本(production release)為止。
縮短驗收測試階段
驗收測試階段帶來很大的痛苦，它感覺相當地不太敏捷。
是的，所以不用。
嗯，好的，我知道. 在某些環境，它看起是不可避免的。但是我的觀點是，我過去曾經認為它是不可避免的。但是，現在我看到許多真的敏捷的公司，藉由放棄單獨的驗收測試階段，把它合併到 sprint 中，以達到行動迅速和提高品質。所以如果你還認為它是不可避免的，這可能是因為你被你的現狀所蒙蔽了（就像我以前一樣）。然而，這個章節提供了一些有用的樣式，讓你知道如何處理獨立的驗收測試，把它當作一個臨時的作法，直到你可以合併的 sprint 裡面。:o)
雖然我們無法擺脫它，我們可以(並)盡量減少它。更具體一點的說，縮短驗收測試階段所需要的時間。我們的作法是：
• 提高Scrum團隊所交付程式碼的品質
• 提高手動測試工作的效率(也就是，挑選最好的測試人員，給他們最好的工具。確保他們所說的很浪費時間的工作，能夠被自動化)
所以那我們如何提高從Scrum團隊所交付程式碼的品質呢？ 嗯，方法有很多。這裡有兩個方法是我們發現非常有用的：
• 把測試人員放到Scrum團隊中
• 每個Sprint中做較少的工作
全站熱搜
留言列表
