當軟件開發組織采用敏捷開發時，測試團隊通常需要花很長時間來完成轉變。在很多公司中，獨立的質量保證團隊已經根深蒂固。當它們開始適應新的敏捷組織時，會遇到難以接受的文化差異。敏捷測試專家Lisa和Janet對此進行了詳細分析，對文化因素在敏捷測試中的影響提出了自己的建議。

　　組織文化通過其價值、標準和設想來定義。組織文化支配著人們如何溝通、交互和做決定，這可以通過觀察員工的行為很容易地看出來。組織文化可以影響敏捷團隊的成功。敏捷團隊適合于允許獨立思考的組織。例如，如果一個公司是等級結構的，所有的項目都鼓勵指令式管理風格，敏捷團隊可能會很吃力。組織以往的經歷也可能會影響新的敏捷團隊的成功。如果公司嘗試敏捷，但是結果糟糕，人們會懷疑再次嘗試的必要性，舉例證明為什么敏捷不起作用。他們甚至可能積極地反對它。

　　當嘗試采用敏捷過程時，組織文化經常被遺忘，人們懷疑敏捷為什么不像承諾的那樣有用。改變已有的過程是困難的，尤其是當人們覺得習慣于現狀時。每個任務組形成了滿足自己需求的文化和過程。他們習慣于自己的工作方式？謶值那榫w非常強大，如果不能妥善解決，可能破壞向敏捷的轉變。如果團隊成員覺得新的敏捷過程威脅他們的工作，那么會抵制這種變化。

　　以如何定義軟件質量的可接受水平的角度思考組織的質量哲學。是否容忍劣質的質量？是否考慮客戶的質量需求，還是只關心是否可以盡快地將產品交付給客戶？當一個組織缺乏全面的質量哲學和團隊沒有生產高質量產品的壓力時，測試人員會感覺到無助。在這種環境中嘗試使用敏捷開發的團隊會面臨更大的障礙。

　　如果一個現有的質量團隊自封為“質量警察”的角色，它的成員通常通過確保完成代碼審查和缺陷嚴謹地記錄到缺陷跟蹤系統來保證質量。他們跟蹤發現的缺陷數，然后負責終決定是否發布產品。我們曾經接觸過一些測試人員吹噓他們的成，例如越過開發經理直接強制程序員遵循代碼標準。甚至聽說有測試人員浪費時間編寫不符合標準的需求的缺陷。這種態度并不符合協作的敏捷團隊，將引起敵對行為！百|量警察”角色的另一個風險是團隊不認同構建質量的概念，程序員將測試人員視為安全防護網。團隊通過缺陷跟蹤系統溝通，但這并不是一種高效的交流，所以團隊并不“凝聚成一團”。

　　技能和適應能力

　　很多程序員不能適應敏捷實踐??但是對于習慣于根據需求文檔編寫測試腳本的測試人員，情況如何呢？他們學會在編寫代碼的時候提出問題了嗎？不能改變測試方式的測試人員與開發團隊的其他人密切工作的時候會很艱難。習慣于通過用戶界面手動測試的測試人員可能無法理解敏捷開發的本質??自動化方式。這些測試人員需要很大勇氣來面對變化的角色，因為變化意味著需要發展其熟悉范圍之外的新技能。

　　輔助因素

　　即使有許多需要考慮的文化因素，但是大部分質量保證團隊關注過程改進，并且敏捷項目通過使用例如回顧總結等工具來鼓勵不斷改進和適應。大多數質量保證專家希望使用他們學到的知識并改進它。這些人適應性強，不僅能適應，并且能在敏捷項目中獲得發展。如果你的組織專注于學習，它將鼓勵持續的過程改進。它將比把更多的精力放在如何應對危險而不是改進過程的組織更快地適應敏捷。

　　如果你是有效的質量哲學的組織中的一個測試人員，你可能努力使質量實踐獲得接受。敏捷方式將提供引入的面向質量的實踐的機制。像其他學習如何在敏捷項目中工作的每個人一樣，測試人員需要時間和培訓。如果管理一個有測試人員的團隊，確保給他們足夠的支持。新項目通常不在一開始引入測試人員，一般讓他們適應一個已經在一起工作了幾個月的團隊。為了幫助測試人員適應，可能需要引入一名有經驗的敏捷測試老師。聘用一名以前在敏捷團隊工作過的員工作為老師和教練可以幫助測試人員融入到新的敏捷文化中，不管是進入一個現有的團隊還是加入一個新的敏捷開發團隊。

　　合適的節奏

　　傳統的測試團隊習慣于在項目結束時快速、激烈地測試，這會導致和夜間的加班。在項目結尾的測試階段，一些組織通常會讓團隊每周工作五十、六十或者更多小時來應付終期限。組織經常將加班作為個人貢獻的度量標準。這與敏捷價值沖突，敏捷價值的中心思想是讓大家時刻以好的狀態工作。

　　在敏捷項目中，鼓勵人們以一個合適的節奏工作。這意味著團隊以一致的速度工作，團隊可以保持在這個保持高質量標準的速度。新的敏捷團隊往往對其能夠完成的工作過分地樂觀，而承諾太多的工作。在一個或兩個迭代之后，會學會承擔不需要加班完成的足夠工作。每周四十小時是極限編程團隊通常的合適速度，這是保證人們連續幾周完成大部分工作并創造優質產品所能承受的工作強度。

　　團隊可能偶爾需要高強度地工作，但是這是特例，不是一般情況。如果需要短期加班，那么整個團隊都應該加班。如果sprint的后某些測試沒有完成，那么整個團隊不僅僅是測試人員都應該加班完成測試。在團隊更好地管理負載和節奏之后，加班才會消失。

　　客戶關系

　　在傳統的軟件開發中，開發團隊和他們的客戶之間的關系更像是買賣關系。即使客戶是內部的，但是感覺更像是兩個獨立的公司，而不是為了生產業務這一目標而共同奮斗的兩個團隊。敏捷開發依賴于客戶或者至少是客戶代表的緊密參與。敏捷團隊邀請客戶協作，如果可能，在同一地點工作，并且密切地參與開發過程。雙方都了解對方的強項和弱點。

　　不管客戶是內部的還是外部的，這種關系的改變需要雙方的認同。開放的關系對敏捷項目的成功至關重要，在敏捷項目中，客戶團隊和開發團隊之間的關系更像是合作關系，而不是買賣關系。擁有一些領域專家代表，并且持續地向所有相關人員報告狀態，是實現開發人員和客戶成功協作的辦法。客戶對敏捷項目的成功是至關重要的。他們對將要實現的功能確定優先級，并對項目的質量有終的評判權。測試人員與客戶緊密合作來理解需求，并定義證明滿足條件已經達到的驗收測試。測試活動對于開發團隊與客戶團隊關系是很重要的。因此，測試專家是敏捷團隊的關鍵。

　　組織規模

　　組織的規模對項目如何運轉及公司如何完善結構有重要的影響。組織越大，結構中的層次可能會越多。當形成自頂向下的交流渠道時，報告結構變得指令化，不適合技術和業務的溝通。