為什么有些軟件測試團隊成功了而另一些卻失敗了？只是因為分配給團隊的具體任務的性質不同嗎？換句話說，成功和失敗是預先注定，不受團隊的控制的嗎？或者，成功的關鍵僅僅只是集合一群“明星”然后讓他們自己干活嗎？相反地，也許成功完全取決于有效的團隊領導？這里的答案是什么呢？
簡短的回答是沒有簡單的方案。任何團隊都必須在自治和受外部管制力量以及團隊內部責任做出響應的需要之間進行平衡。雇傭明星顯然對團隊建設有幫助，但是那不是對成功的保證。
本文探討了區別高效能測試團隊的一些具體特征。目的是幫助軟件測試工程師和管理者了解這些特征，以及如何在他們自己的團隊中培養這些特征。
優秀測試團隊的特征
一個團隊之所以成為一個高效能團隊，人們有很多老套的描述方法，比如：“團隊中沒有自我”，“整體作用大于局部作用之和”。這些都指出一個優秀團隊不是一群個體，而是一個有凝聚力的集體。盡管如此，有效的軟件測試團隊還共有一些更微妙（不太老套）的特征。我們將從探討這些特征開始。
測試團隊有明確定義的角色任務
John Donne認為，任何軟件工程師，任何軟件工程師組成的團隊，都不是一座孤島。你可能獨自為公司寫代碼長達數小時，但是你的成功取決于你所在團隊的伙伴成員的努力。而你的團隊的成功又取決于其它團隊的努力。
若想在相互依賴的軟件開發和測試中取得成功，團隊必須把責任、交付品、以及支配團隊成員如何與他人互動、團隊之間如何把互動的協議清楚地定義出來。換句話說，團隊必須為團隊內外的任務建立社會契約；它們定義了團隊成員作為個人的角色以及團隊在其它團隊的大環境中的角色。
為什么這樣做是必要的呢？首先，它使得團隊集中于實現它的目標；沒人需要像偵探一樣去發現目標究竟是什么，也無需像律師一樣去為目標辯護。
第二，如果沒有這樣一份社會契約，一個軟件項目，或任何具有復雜人員結構的企業，都將會像一個“沒有法制的國家”那樣工作。換句話說，控制項目團隊及其成員如何工作的過程將僅僅只基于某些具體相關人員的個人經驗，個人判斷，以及失敗經歷。沒有清楚定義，清楚記錄下來的可供每個人遵循的規則集。 1 項目的成敗將完全依賴于那部分人預見問題、領會他人問題和無私為項目更好完成尋求路徑的能力。在這樣的情況下，有多少人能獲得你的信任呢？
詳細定義的開發和測試流程，控制軟件項目的程度各有不同，取決于項目環境。有些項目是圍繞一個詳細定義的、全面的過程來組織的，比如 IBM Rational Unified Process，簡稱 RUP 2 ；而另一些項目則用了比較特別的方式。在后一種情況下，軟件測試團隊必須從起草它的角色并與其他項目團隊建立社會契約開始。在前一種情況下，定義測試團隊的角色的工作量稍小，但是項目領導不能簡單地說，“我們按照過程進行�！彼麄儽仨毧紤]項目獨特的要求和需求。正如 Thomas Watson 先生經常說的，“你必須記得，要思考！”
測試團隊是多樣的
現在，當人們聽到“多樣性”這個詞，他們會想到關于近來保證公司勞動力方面的事情，公司的勞動力大致反映整個社會的宗教，種族的組成部分。當你組建軟件測試團隊時，也必須考慮到團隊成員的技能，個性，以及經驗的多樣性。盡管你可能認為軟件測試團隊成員應該相對來說都是差不多的，最強的團隊卻是由一組具有多樣性技能的個體成員組成的。讓我們詳細分析這點；然后我們回顧一下你在組建你的團隊是需要組合的性格和技能類型。
人們經常用體育上類似的情況來描述商業或工程團隊的運作；實際上，這種類比在商業通信上已經很老套了。盡管如此，有趣的是，在某一段時間這些陳詞濫調曾反映了精確和新穎的思想。比如說，如果你和我一樣在美國 Massachusetts 的 Boston 附近長大，而且你對體育不是毫無興趣，那么你很快就會知道 1967 年Boston Red Sox 棒球隊的故事。那一年，這支隊伍在二十年的失敗后贏得了它的第一個聯賽冠軍。他們不是依靠組建一支全明星隊伍，而是組建了一支擁有少數“明星”，多數有潛力但缺乏經驗的年輕隊員，以及有經驗，但不出名，可以擔任多種角色的隊員的隊伍。那是一支多樣化的隊伍，而且巧合地，他們非常有激情。它是成功的，不僅因為有些隊員在整個賽季表現出色，還因為整個隊伍的技術和性格構成很合理。
同樣類型的多樣性在建立一支成功的軟件測試團隊中也很重要。相對來說，量化技能比較容易，比如使用Java之類的具體程序設計語言的水平，或者使用J2EE之類結構工具的經驗。但是怎樣評價其他經驗、思維過程、愛好、實踐能力、見解等等這些你在團隊成員身上需要的東西呢？
文章來源于領測軟件測試網 http://www.kjueaiud.com/