靈活測試的團隊構成

　　獨立的品質保證團隊

　　許多組織，不管大還是小，為了得到關于産品品質的誠實的觀點，認為擁有獨立的品質保證團隊或測試團隊是很重要的。經常有人問我們：“在整體團隊運作方式中有測試組織的位置嗎？”以及“如果有，是什麼角色？”希望保持品質保證團隊與開發團隊分離的原因有：

　　● 擁有獨立的檢查和審計角色很重要。

　　● 獨立的品質保證團隊可以對産品的品質提出沒有偏見的外部觀察的觀點。

　　● 如果測試人員與開發人員過于親密，将會像開發人員那樣思考，丢失客戶觀點。

　　● 如果測試人員和開發人員向同一個人彙報，可能會有風險使得傳遞任何代碼的優先級大于傳遞已測試代碼的優先級。

　　我們不相信将測試人員整合到項目團隊會妨礙測試人員正常的工作。實際上，靈活團隊的測試人員感覺其客戶代表的角色很明顯，并且認為可以在品質思想方面影響團隊的其他成員。

　　把測試人員整合到靈活項目

　　janet曾幫助過整合幾個獨立的測試團隊到靈活項目。她發現大部分測試人員需要六個月的時間開始對使用新的過程感到有信心。

　 　程式員和測試人員的結對隻可能促進關于産品品質的交流。如果應用的行為不能在開發環境中重制，開發人員通常需要在測試人員的機器上觀察應用的行為。測試 人員有時與開發人員一起坐下重制問題會比他們嘗試在缺陷報告中記錄步驟更容易和快速。這種互動減少了用于非口頭交流的時間。

　　測試人員關于這個話題的評價包含如下幾條：

　　● “更接近産品的開發讓我成為更出色的測試人員。”

　　● “與開發人員一起吃午飯可以建構更優秀的團隊，這個團隊希望并且喜歡一起工作。”

　　整合的項目團隊的一個重要優勢是隻有一個預算和一個進度安排。如果所有的功能沒有完成，不會減少“測試”時間。如果沒有時間測試新的特性，則首先沒有時間來開發它。正如貫穿本書強調的那樣，整體團隊對品質負責是非常強大的。

　lisa分享了自己的故事：

　　我曾經加入過極限程式設計團隊，隻依賴于單元級的測試，以前從來沒有過測試人員的角色。客戶有時對結果不滿意，是以他們決定聘用一名測試人員。當我 參加每日站立會議時，他們不允許我說測試任務。使用者故事評估中不包含測試時間，測試任務也不是疊代計劃的一部分。隻要編碼任務完成，使用者故事就被标記為 “完成”。

　　團隊超過釋出日期後，計劃在三個兩周疊代後釋出，我建議團隊教練嘗試整體團隊運作的方式來測試。測試任務與編碼任務一起進行。在測試任務沒有完 成之前，不能認為使用者故事已經結束。程式員承擔測試任務，我完全參與到每日站立會議中。團隊此後再也沒有錯過他們設定的釋出計劃。

　　測試人員需要是開發團隊的正式成員，測試任務需要和其他任務一樣的重視。并且，用整體團隊運作的方式來測試可以顯著幫助確定測試任務在每個疊代 及釋出的末期完成。確定用回顧總結來評估測試人員需要與新靈活團隊整合什麼，及需要擷取什麼技能。例如，測試人員可能需要程式員或某種特定類型的測試專家 的更多支援。

　　組織轉變到靈活開發的良好規劃會使這種成功的過程截然不同。請品質保證和開發經理指定出他們在新的靈活組織中的角色。請他們計劃如何幫助測試人 員和開發人員在新的靈活團隊中高效地工作。提供團隊靈活實踐教育訓練。確定所有的團隊可以互相交流。提供讓每個團隊不斷學習的架構，團隊就會找到成功的道路。

　　執行個體研究：轉變品質保證和項目團隊

　　christophe louvion是知名網絡公司的首席技術官和靈活教練。他告訴我們幫助公司使用靈活開發的經曆。作為靈活教練，他希望真正地使用靈活開發，避免常見的“小型瀑布”的錯誤，即開發人員花一周編碼，測試人員下一周測試。

　　他的公司包括内部的it部門當時有120名工程師。在轉變到scrum前，公司的組織正常工作。因為有品質保證和工程總監，基于産品的團隊很難 得到管理層的接受。這些團隊的經理用下面的問題與之鬥争：“我的工作現在是什麼？”christophe将這個問題轉給經理們并說：“你們回答我。”他同 工程和品質保證經理們一起工作來幫助他們明白在新的靈活環境中的工作應該是什麼。隻有當他們用同樣的聲音說話時，他們才能融入團隊并解釋他們的發現。

　　在新的靈活組織中，經理們處理特定領域知識、資源、優先級和提出的問題。工程和品質保證經理們每天聯合工作來解決這些類型的問題。 christophe和兩個經理研究測試人員在兩周疊代的第一個星期沒有工作效率的原因并指導他們如何幫助設計。對于程式員來說，問題是“我如何做才能讓 代碼容易測試？”因為工程師們習慣于階段周期的工作，沒有過在持續內建方面的教育訓練，需要測試驅動設計、持續內建和實踐等方面的許多教育訓練。經理保證了他們獲 得這些教育訓練。

　　引入了配置管理（cm）專家來幫助建構過程。在公司中，cm團隊與工程和品質保證團隊是分離的，提供建構過程中所有方面的架構，包括資料庫對象、硬體和配置。一旦實作了建構過程，內建編碼和測試将會更加容易

　　管理層首先确定他們的角色，然後把所有東西都放入源碼控制的建構過程架構，是成功轉變到靈活的關鍵。另一個成功因素是所有的團隊——項目、品質 保證、配置管理、網絡和系統管理小組及産品團隊——都有回顧總結，參與每日站立會議和計劃活動。這樣，當出現測試問題時，每個可以幫忙的人都可以解決。如 christophe所說，他們的方法引入了每一個人并且突出了測試。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/