關于軟件測試的幾點反思 - 關于測試團隊的組織

　　這一篇是系列文章的第三篇，前面兩篇分別談了測試的必需性(http://blog.csdn.net/superqa/article/details/21406611)，以及測試工作的一些內容(http://blog.csdn.net/superqa/article/details/21485737)，接下來想聊一下測試團隊的組織。

　　要討論這個話題，首先要討論下測試人員本身的歸屬，因為通常是人多了才有組織的必要，很多東西都是一點點長出來的。

　　我在讀研期間實習的一家公司，根本沒有專職的測試人員，回頭想想當時還是挺大膽的，因為做的是比較核心的系統，而且當時像我這種實習生都寫了很多核心的涉及金額計算的代碼，然后大家自測下就上線了。這種情況也持續了好久，也驗證了不一定必需，在特定的情況下。

　　個人的工作經歷，沒有一開始去很小的研發組織。后面工作后的面試中，也接觸過很多規模較小的公司的測試人員，這種情況下大部分是直接歸屬到項目，匯報給開發經理。人數少，大部分是比較基礎的黑盒測試，相對也比較弱勢。沒有任何貶低的意思，但是客觀來說，這個階段的測試很難有一些比較深入的測試技術上的實踐，時間不允許，也處于沒有人帶的情況，大家基本上都專注在項目的功能測試上面。一直覺得環境對人的影響是比較大的。有些比較有上進心的同學會自己學一些技術，但是因為沒有指導，也沒有實際應用的場景，通常比較淺。

　　后面等到整個研發體系發展大了之后，可能測試人員也慢慢多了起來，同時服務于多個開發小組，于是就出現了測試團隊的二級組織。比如對口每個開發小組的有幾個人，或者更多，然后有一個lead或者first line manager，然后這些人匯總到一個second line的manager。這個時候隨著測試團隊規模的壯大，當然也是隨著整個研發組織的壯大，以及業務和開發方面提出了更多更高的質量要求，測試團隊在客觀上有了進一步提升的需求。主觀上因為second line的出現，會不再滿足于完成基本的測試工作，也有提升的動力。一些測試的規范，用例設計，缺陷管理，數據的分析，工具平臺的引入，自動化的開展等慢慢開始引入。

　　接下來，可能到研發部門層面有一個完整的測試團隊，進而可能是整個公司，或者事業部(BG，BU)層面有一個完整的測試部門，或者中心。

　　目前看到的騰訊和阿里的幾個大的業務導向的事業部都是這樣的情況，比如騰訊的互聯網，互動娛樂，電商(曾經);阿里的淘寶，天貓和支付寶，都是在事業部層面有一個完整的測試團隊。

　　進一步，如果這類很大型的公司，把全集團的測試集中到一起的還沒看到，主要是因為組織架構的頂層還是按業務來劃分的，比如事業部制。

　　基于上面的討論，我們可以從測試的集中這種角度來看看測試團隊的情況，這樣劃分就有兩種，集中還是不集中。

　　集中的例子就是上面說的情況，所有專職測試人員都在一個小組，一個大的二級組，進而一個中心，一個部門，數據結構上是一顆樹。非集中的情況就是測試人員散落在不同的開發中心，或者開發組，是一個森林。每一塊的測試人員組成一個小組，匯報給開發中心的總監，或者開發經理。 目前了解到不少公司是這樣來組織的。

　　每一種組織方式都是結合了公司的實際情況和要求，但是如果單純從測試團隊的價值和效率方面，目前來看，會覺得集中到一起是個更好的方式，主要的理由是下面幾點。

　　1. 集中到一起之后，因為資源的整合，可以減少各個團隊的重復建設，集中來做一些平臺建設，技術研究，或者橫行的技術共享，有利于提升團隊的技術深度。

　　2. 從業務的角度，集中后測試可以橫向的對齊，來看各個項目的質量情況，研發流程的過程執行和效率的情況。從整個組織的角度，對研發的質量和效率有促進的作用。

　　3. 從測試人員個人發展的角度，因為整個測試組織有了更好的深度，個人發展的空間也會更大，無論技術還是管理方面。

　　4. 測試人員的歸屬感，有自己的部門和自己的職業發展通道。

　　談到和項目的對應，目前采用測試集中方面的團隊也基本上是矩陣式管理，特別是針對負責業務測試的小組。一方面，從組織架構上是歸屬于質量部或者質量中心，但是從日常工作上，是歸屬到項目或者產品，和對應的產品、開發團隊密切配合，包括座位可能都在一起。

　　就目前觀察的情況來看，這種組織架構相對是比較成熟，也比較普遍被采用的，運作起來也還比較順暢。

原文轉自：http://blog.csdn.net/superqa/article/details/21966881