一個測試管理者在考慮提升組織的測試能力、進行一系列測試改進時，除了考慮測試技術本身的因素外，還有一項不能忽略，那就是測試的組織結構。
《TPI Next》里面劃分測試關鍵域時，專門單獨劃分了一個“test organization”的key area，并且定義“A test organization meets the needs of projects for test resources， test products and test services.”，認為測試組織就是關于“the right people expertise and experience at the right place.”的事情。 本文探討的測試的組織結構只是“test organization”的一部分，重點探討測試的組織結構如何與開發(fā)的組織結構相對應的問題，基本上對應TPI里的controlled level，即“A test organization enables uniformity in test approach， test products and procedures， agreements and clear test results.”
為什么 談測試管理時，要談測試的組織結構？其實，組織結構在有關測試管理的探討中有著不可忽視的作用，它體現(xiàn)著管理思想，也反過來對測試管理有輔助的作用，這就 像經(jīng)濟基礎決定上層建筑一樣，測試管理理念達到了什么層次，就會制定相應的測試組織結構，以更好的落實這個理念。實踐證明，很多測試過程中出現(xiàn)的問題最后 都與組織結構有關系。
而談到測試的組織結構時，勢必要先參考開發(fā)的組織結構。對于傳統(tǒng)的瀑布開發(fā)模式而言，一個系統(tǒng)有可能會劃分為幾個模塊來實現(xiàn)，開發(fā)的組織結構基本上是和模塊一一對應的，我們就拿這種典型的情況討論一下相應的測試組織結構應該如何劃分。
一個產(chǎn)品的開發(fā)可以分解為多個模塊來實現(xiàn)，這個產(chǎn)品的某個功能或特性經(jīng)常需要多個模塊配合實現(xiàn)。假如每個模塊對應一個開發(fā)項目組，測試項目組的劃分經(jīng)常會有兩種選擇，一是也按照模塊劃分，二是按照特性劃分，一個特性可以跨多個模塊。那么二者各有什么優(yōu)缺點呢？
按照模塊劃分的測試項目組，由于和開發(fā)項目組存在一一對應的關系，二者關系更為緊密，開發(fā)人員和測試人員的交流也更為順暢，會經(jīng)常一起探討模塊級的細節(jié) 和實現(xiàn)，有利于在產(chǎn)品開發(fā)階段（發(fā)布給測試前）測試人員的前期介入，這種前期介入包含很多方面，例如測試人員對設計文檔的評審檢視、測試分析與設計的分工 合作、測試人員參與的前期代碼走讀、集成測試等等，更多地測試前期介入的內(nèi)容可參考這篇blog。 因此，按照模塊劃分的測試組織對模塊會進行比較充分的測試，但這種模式也存在一些弊端，比如對于涉及到多個模塊的特性，測試人員在測試分析設計和評審檢視 中往往考慮欠佳，測試人員對整個系統(tǒng)層面的把握不是很到位，同時測試人員和開發(fā)人員的過于“親密”也造成測試無法扮好“黑臉”的角色。
按照特性劃分的測試項目組，對上述弊端可以做到較好的規(guī)避。但這個時候常常是測試為了避免受開發(fā)思路的太多影響，獨立彰顯測試的價值，從測試設計到測試執(zhí) 行都會另起一套，更多的從測試的角度、從客戶的角度考慮問題，更多的站在特性一級、系統(tǒng)一級考慮問題，測試在把系統(tǒng)當作一個黑盒進行系統(tǒng)測試方 面越來越擅長，此時的測試管理者如果不注意把握一個“度”的話，就會出現(xiàn)“測試后移”的現(xiàn)象，測試人員把眼光聚焦在后端，致力于問題發(fā)現(xiàn)，漸漸的，代碼走 讀、集成測試等前端測試的活動測試做的偏少了，甚至都移交給了開發(fā)人員。可是開發(fā)人員“天生”的對問題不敏感，其質(zhì)量難以保證，很多開發(fā)人員認為開發(fā)人員 所做的測試“測不徹底”是很正常的事，反正后面有測試人員做后盾。那么時間長了，這種模式的弊端也會逐漸暴露：純黑盒的系統(tǒng)測試周期拉得很長，因為缺陷遲 遲不能收斂，開發(fā)在版本轉測試后也疲于奔命修改問題單使得人力遲遲無法釋放；如果產(chǎn)品的需求控制不好的話，新需求的不斷合入會加劇問題的惡化，新需求將無 法得到有效跟蹤、設計和驗證；很多本應該在UT、IT發(fā)現(xiàn)的問題都遺留到了系統(tǒng)測試階段，測試部為了保證產(chǎn)品的質(zhì)量，花費大部分時間驗證這些前期遺漏的問 題，而沒有精力站在客戶角度、從組網(wǎng)場景、應用場景開展對需求的系統(tǒng)級驗證，導致問題在網(wǎng)上頻頻爆發(fā)；而如果測試人員穩(wěn)定度不高時，測試人員的不斷更新， 會導致了解系統(tǒng)內(nèi)部實現(xiàn)的測試人員越來越少，隨著產(chǎn)品的快速更新演進（對比較復雜的產(chǎn)品而言），測試人員在系統(tǒng)架構層面的討論上顯得力不從心，等等。
那么究竟應該選擇什么樣的組織結構才會最大化測試效率呢？答案是沒有定論。這要結合開發(fā)的組織結構、開發(fā)模式、測試人員構成、產(chǎn)品復雜度、需求穩(wěn)定度、組織的測試經(jīng)驗積累、當前產(chǎn)品的軟肋是模塊還是系統(tǒng)等因素綜合考慮。
但是至少有兩點是可以確定的：
1）上述兩類典型的測試組織結構無論選取哪一種，都與測試組織的成熟度沒有必然的關系；
2）無論選取上述的哪一種，甚或是第三種、第四種，組織結構都不是一成不變的。實際上，有的組織會經(jīng)常在這兩種組織結構形式之間來回變換，以適應不同的歷史形勢。