各自分離的功能小組會讓敏捷團隊更困難。持續的交流至關重要。團隊成員需要互相親密地工作，不管工作是通過虛擬環境還是在同一個地點完成。敏捷測試專家Lisa和Janet分享了敏捷測試團隊的組織經驗。
獨立的質量保證團隊
許多組織，不管大還是小，為了得到關于產品質量的誠實的觀點，認為擁有獨立的質量保證團隊或測試團隊是很重要的。經常有人問我們：“在整體團隊運作方式中有測試組織的位置嗎？”以及“如果有，是什么角色？”希望保持質量保證團隊與開發團隊分離的原因有：
● 擁有獨立的檢查和審計角色很重要。
● 獨立的質量保證團隊可以對產品的質量提出沒有偏見的外部觀察的觀點。
● 如果測試人員與開發人員過于親密，將會像開發人員那樣思考，丟失客戶觀點。
● 如果測試人員和開發人員向同一個人匯報，可能會有風險使得交付任何代碼的優先級大于交付已測試代碼的優先級。
團隊經常混淆“獨立的”和“分離的”。如果匯報結構、經費和過程保持在離散的功能區域，程序員和測試人員間的分離是必然的。這可能導致摩擦、競爭和“我 們VS他們”的態度。時間浪費在重復的會議上，程序員和測試人員沒有共同的目標，更不存在信息共享。雖然有許多原因需要質量保證經理和獨立的測試團隊。但 是，我們建議改變原因和結構。與其保持測試人員作為對立的團隊分離，在編碼完成后測試應用，不如考慮將團隊作為測試人員團體。提供一個學習性組織來幫助測試人員職業發展和分享想法及互相幫助。如果質量保證經理成為組織中的實踐領導，人們將可以傳授給測試人員技能使其變得更強并更好地適應不斷變化的環境。
我們不相信將測試人員整合到項目團隊會妨礙測試人員正常的工作。實際上，敏捷團隊的測試人員感覺其客戶代表的角色很明顯，并且認為可以在質量思想方面影響團隊的其他成員。
把測試人員整合到敏捷項目
敏捷開發中的整體團隊運作方式已經促使很多采用敏捷開發的組織解散獨立的質量保證團隊，將測試人員與項目組一起工作。這聽起來很好，但是有些組織發現事 與愿違。不止一個組織已經導致大部分（如果不是）所有測試人員因為發覺他們在敏捷開發團隊中不知道應該做什么而離職。培訓開發人員結對編程、測試驅動開發 和其他的敏捷實踐，但是測試人員通常得不到任何培訓。許多組織沒有意識到測試人員也需要培訓結對測試、處理不完整和變化的需求、自動化和需要的所有其他新 技術。測試人員接受培訓和輔導來獲取技能并認識到這些將對于成功是很重要的，例如如何與客戶一起編寫面向業務的測試。程序員也可能需要輔導和理解面向業務 測試的重要性以及整體團隊運作方式來編寫和自動化測試。
Janet曾幫助過整合幾個獨立的測試團隊到敏捷項目。她發現大部分測試人員需要六個月的時間開始對使用新的過程感到有信心。
程序員和測試人員的結對只可能促進關于產品質量的交流。如果應用的行為不能在開發環境中重現，開發人員通常需要在測試人員的機器上觀察應用的行為。測試 人員有時與開發人員一起坐下重現問題會比他們嘗試在缺陷報告中記錄步驟更容易和快速。這種交互減少了用于非口頭交流的時間。
測試人員關于這個話題的評價包含如下幾條：
● “更接近產品的開發讓我成為更出色的測試人員。”
● “與開發人員一起吃午飯可以構建更優秀的團隊，這個團隊希望并且喜歡一起工作。”
整合的項目團隊的一個重要優勢是只有一個預算和一個進度安排。如果所有的功能沒有完成，不會減少“測試”時間。如果沒有時間測試新的特性，則首先沒有時間來開發它。正如貫穿本書強調的那樣，整體團隊對質量負責是非常強大的。
Lisa分享了自己的故事：
我曾經加入過極限編程團隊，只依賴于單元級的測試，以前從來沒有過測試人員的角色。客戶有時對結果不滿意，所以他們決定聘用一名測試人員。當我 參加每日站立會議時，他們不允許我說測試任務。用戶故事評估中不包含測試時間，測試任務也不是迭代計劃的一部分。只要編碼任務完成，用戶故事就被標記為 “完成”。
團隊超過發布日期后，計劃在三個兩周迭代后發布，我建議團隊教練嘗試整體團隊運作的方式來測試。測試任務與編碼任務一起進行。在測試任務沒有完 成之前，不能認為用戶故事已經結束。程序員承擔測試任務，我完全參與到每日站立會議中。團隊此后再也沒有錯過他們設定的發布計劃。
測試人員需要是開發團隊的正式成員，測試任務需要和其他任務一樣的重視。并且，用整體團隊運作的方式來測試可以顯著幫助確保測試任務在每個迭代 及發布的末期完成。確保用回顧總結來評估測試人員需要與新敏捷團隊整合什么，及需要獲取什么技能。例如，測試人員可能需要程序員或某種特定類型的測試專家 的更多支持。
組織轉變到敏捷開發的良好規劃會使這種成功的過程截然不同。請質量保證和開發經理指定出他們在新的敏捷組織中的角色。請他們計劃如何幫助測試人 員和開發人員在新的敏捷團隊中高效地工作。提供團隊敏捷實踐培訓。確保所有的團隊可以相互交流。提供讓每個團隊不斷學習的框架，團隊就會找到成功的道路。
實例研究：轉變質量保證和項目團隊
Christophe Louvion是知名網絡公司的首席技術官和敏捷教練。他告訴我們幫助公司使用敏捷開發的經歷。作為敏捷教練，他希望真正地使用敏捷開發，避免常見的“小型瀑布”的錯誤，即開發人員花一周編碼，測試人員下一周測試。
他的公司包括內部的IT部門當時有120名工程師。在轉變到Scrum前，公司的組織正常工作。因為有質量保證和工程總監，基于產品的團隊很難 得到管理層的接受。這些團隊的經理用下面的問題與之斗爭：“我的工作現在是什么？”Christophe將這個問題轉給經理們并說：“你們回答我。”他同 工程和質量保證經理們一起工作來幫助他們明白在新的敏捷環境中的工作應該是什么。只有當他們用同樣的聲音說話時，他們才能融入團隊并解釋他們的發現。
在新的敏捷組織中，經理們處理特定領域知識、資源、優先級和提出的問題。工程和質量保證經理們每天聯合工作來解決這些類型的問題。 Christophe和兩個經理研究測試人員在兩周迭代的第一個星期沒有工作效率的原因并指導他們如何幫助設計。對于程序員來說，問題是“我如何做才能讓 代碼容易測試？”因為工程師們習慣于階段周期的工作，沒有過在持續集成方面的培訓，需要測試驅動設計、持續集成和實踐等方面的許多培訓。經理保證了他們獲 得這些培訓。
引入了配置管理（CM）專家來幫助構建過程。在公司中，CM團隊與工程和質量保證團隊是分離的，提供構建過程中所有方面的框架，包括數據庫對象、硬件和配置。一旦實現了構建過程，集成編碼和測試將會更加容易
管理層首先確定他們的角色，然后把所有東西都放入源碼控制的構建過程框架，是成功轉變到敏捷的關鍵。另一個成功因素是所有的團隊——項目、質量 保證、配置管理、網絡和系統管理小組及產品團隊——都有回顧總結，參與每日站立會議和計劃活動。這樣，當出現測試問題時，每個可以幫忙的人都可以解決。如 Christophe所說，他們的方法引入了每一個人并且突出了測試。