14 . 我們怎樣做測試
藉由把測試人員放到Scrum團隊中來提高品質
是的，我聽過完全不同的說法：
• "但是，那很明顯啊！ Scrum團隊理應是跨功能職務的"
• "Scrum團隊裡應該是沒有角色的！ 我們不能有一個人僅僅只是在做測試"
讓我澄清一下，在這裡我所謂的"測試人員"是指"一個主要技能是測試的人"，而不是"一個它的角色只是在做測試的人"。
這是一個重要的觀點。 “跨職能”並不意味著每個人要會所有的東西。它的意思只是每個人願意去做，超過他們所負責的部分。我們需要的是專業化與跨職能化，取得一個合適的平衡。所以，整個團隊共同為他們的產品的品質負責，所以每個人都被要求要做測試。然而，測試人員需要指導這工作的進行，和開發人員配對去做測試自動化，自己則執行更複雜的手動測試。
開發人員通常是相當差勁的測試人員，特別是在測試他們自己的程式碼的時候。
測試人員就是"驗收的傢伙"
除了"只是"團隊的一員外，測試人員有一個重要的工作，他是驗收的傢伙。在Scrum中，要直到他說完成才算完成，否則沒有事情能算"完成"。我曾經發現，開發人員常常說某件事情已經完成，但是實際上還沒有。即使你有非常清楚"完成"的定義(你應該如此，請看"'完成'的定義")，開發人員還是經常忘記。我們這些程式設計師常是沒有耐心的人，只想要很快的進到下一個Sprint。。
那我們的測試先生如何知道某些事情已經做完呢？ 嗯，首先，他應該(很驚訝吧)測試它！ 在許多狀況下，那些開發人員認為已經做完的項目，結果是不可能被測試的。因為那些東西還沒被check-in，或是還沒被部署到測試伺服器中。一但測試先生開始測試時，他應該和開發人員，從頭到尾確認過那份"做完"的清單(如果你有的話)。例如，如果在"做完"的定義中，描述應該有個發佈說明，那測試先生要檢查是不是有個發佈說明。如果這個功能有某種更為正式的規格，那測試先生也要檢查，等等。
這裡有一個很好的副作用，因為團隊現在有一個傢伙，非常適合安排做Sprint展示的工作。
我不再是簽核這種模式的粉絲了。這將會產生瓶頸，並且將太多責任放到一個人的手上。但是，我認為在某些環境下，簽核還是有用的(在某些時間，它一定有用) 。此外，如果有任何人必須要對品質簽核的話，那個人一定是真實客戶。
當沒有東西要測試時，測試人員要做什麼？
這個問題常常被提出來。測試先生說： "嗨，Scrum master 現在沒有東西要測試，所以我要做什麼？" 團隊可能需要一個禮拜，才能完成第一個故事。那這時候測試人員應該做什麼？
好的，首先，他應該要為測試做些準備。那就是撰寫測試規格書，準備測試環境，等等。所以當開發人員已經有東西可以被測試時，就不用再等待，測試先生可以立即開始測試。
如果團隊有做TDD，那大家從第一天開始，就會花時間撰寫測試程式碼。測試人員應該和開發人員撘檔編程，一起撰寫測試程式。如果測試人員一點都不會寫程式，他也應該和開發人員撘檔編程。即使他只能瀏覽，而開發人員去敲鍵盤。一個好的測試人員總是會比好的開發人員，想出更多不同種類的測試，所以他們可以互相互補。
如果團隊沒有採用TDD，或是沒有足夠的測試個案需要去撰寫，他應該完全地盡他所能，幫助團隊實現Sprint的目標。就像團隊其他成員一樣，如果測試人員會寫程式，那很好。如果不會，你的團隊必須找出需要在Sprint中完成，但不用寫程式的工作。
在Sprint規劃會議中，把故事拆解成任務時，團隊著重於編程的工作。然而，通常還有許多非編程的工作，需要在Sprint中完成。在Sprint規劃會議中，如果你花時間，企圖找出非編程的工作，測試先生將會有機會去貢獻許多，即使他不會寫程式，或者目前沒有測試工作要進行。
這裡有些非編程的任務，需要在Sprint中被完成：
• 建置測試環境。
• 釐清需求。
• 和營運部門討論佈署的細節。
• 撰寫部署的文件(發佈說明，RFC，或是任何你組織中要寫的東西)。
• 和外部資源進行聯繫 (例如GUI設計師) • 改善建構腳本(build scripts)
• 進一步將故事拆解成任務
• 從開發人員中找出關鍵的問題，並解決他們。
從另一個角度來看，如果測試先生變成是瓶頸，那我們該怎麼辦？ 假設我們現在在Sprint的最後一天，突然間有很多工作被完成，導致測試先生沒有去測試完所有事情，那我們要怎麼辦？ 嗯，我們應該叫團隊中所有人去測試先生當助手。他來決定哪些事情他自己要做，然後把一些平凡的測試交給團隊中其他人來做。這就是跨功能職務團隊所該做的事情！
所以，是的，測試先生在團隊中，確實是一個特別的角色，但是他仍然可以去做其他工作，其他團隊成員也被允許去做他的工作。
說得好！（我可以被允許有時候誇獎一下自己嗎？）這是一個觀察團隊成員其他能力的好方法。
全站熱搜
留言列表
