最近流行“三問”。對於測試團隊來說，也可以有三個問題，測試團隊是如何建立和發展起來的？以後又會向何種模式發展？最終會消亡麼？本文嘗試梳理在企業發展過程中可能存在的各種測試資源的組織形式，並認為“無測試”是測試組織對內職責發展的高階形態，而測試組織對外提供服務，成為“前臺部門”的這種“第三方模式”是另一種高階形態。這是一種線性發展的模式。隨著公司從初創到發展壯大，測試人員也從無到有，再壯大成立測試小組，並一路發展成為測試部門，然後在內部繼續分化出不同的職能分工。
通常存在一個統一的測試部門或者測試中心，負責整個公司層面或者業務BU層面的測試和質量相關的工作。在一些大型的測試組織中，進而會進一步派生出功能測試、自動化測試、效能測試、安全測試等專項的測試團隊，以及流程與質量控制等角色。可以說在進入網際網路時代之前，這種集中模式是一種主流的測試資源組織模式。這種模式可以高效地利用測試資源，對測試人員的專業性發展也提供了深度。在一些處於強監管的金融行業，強調職責之間的隔離，也通常採用這種形式。這在一線的網際網路公司以及擁有多條產品線的傳統IT公司非常常見。隨著公司成為一個集團公司，跨入眾多的行業和領域，集中式的研發團隊甚至也不再是一個選項。IT資源被分散到各個BU，而相應的，測試團隊也伴隨著IT團隊進入業務BU，互相獨立決策和獨立管理，彼此之間互不隸屬，不再有一個統一的集團總部，來統一領導這些測試組織。
可能有些公司還會設定顧問角色或者建立鬆散的俱樂部等實現跨BU或者部門之間的測試流程、質量標準等通用性測試基礎設施的協同。從IT治理的角度，集中和分散兩種模式都存在一定的侷限性。過於集中導致IT作為一種治理手段，沒能發揮應有的作用（silo,倉桶），而過於分散的後果往往是對IT的控制力度不夠，產生各種成本和安全的問題。
因此也有很多企業選擇了集中與分散相結合的測試組織結構，即存在一個集中的測試團隊，來負責產品或者產品線的整體交付質量，包括測試基礎設施的建設以及各型別專項測試甚至使用者驗收測試的實施。而分散的測試資源往往是存在於各個開發團隊內部，更為主動地融入團隊，提供更為及時有效的質量溝通和反饋。似乎走上了一條資源共享、統一規劃、緊密結合的道路。另外一種典型的是很多采取專案制的公司，集中式測試組織成為一個測試資源池，為專案團隊不斷地培養和輸出測試資源，提供培訓和指導。在某些大型集團，會將其部分測試職能以外包或者內包的形式轉移到第三方，從而能夠利用第三方的資源，更好地解決企業內部面臨的測試與質量的需求。
採用外包模式的關鍵是企業和第三方需要簽訂相關的服務水平協議(SLA),一些常規而又需要一定專業技能和基礎設施的專案，如安全測試、效能、App測試等，可以由專業第三方公司提供支援服務。而一些集團公司為了降低每個分支機構的成本、集中優勢人力資源，會成立卓越測試中心(TCOE)，共同為各分支機構提供服務，其定位相當於是內部乙方，各分支機構按照服務工作量結算或者虛擬結算。而這樣的測試中心如果再往前走一步，就是單獨公司化運作，即可以為企業內部提供全面的測試和質量服務，又為外部客戶提供服務。進而從一個公司的技術後臺部門走向前臺，成為一個“業務”部門。敏捷宣言給IT業界帶來了新的思維，一時風頭無二，對測試團隊也帶來了非常大的衝擊。《Agile Testing 敏捷測試》和《How Google Test》相繼問世後，一種“新”的測試組織結構被很多公司採用，既所謂的“去測試”風潮，後者在書中宣稱，“測試經理是一個沒有前途的職業”。很多，實施“敏捷”的公司，拆散了統一的測試團隊，將測試人員併入開發團隊，與開發人員一樣彙報給相同的管理者，譬如開發組長或者專案經理。
這種模式一度非常流行，不少公司辭退了測試總監/經理，或者讓其轉型帶來敏捷團隊，成為一線領導者。《How Google Test》甚至在書中宣稱，“測試經理是一個沒有前途的職業”。實施敏捷最終演變成了“去測試管理崗位”，對於一線測試員工來說，只是換了一個團隊和彙報物件，其工作內容並沒有發生實質性改變。這種模式的優勢，是開發和測試人員在同一個團隊工作，溝通合作會順暢很多。少了跨團隊/部門的測試交接，對於產品交付來說也會更加順暢。當然，透過筆者的觀察，這種測試進入團隊的模式是一種很容易被打破的非平衡態。那些在這種非穩態下成功轉型的團隊，會進入下一個階段。根據《How Google Test》的描述，進入這個階段的團隊，基本上是這樣的一種模式。
- 團隊擁有一大筆Old Money,既一套覆蓋較為全面的自動化測試用例。
- 新增特性/程式碼得到了較為充分的測試，當然這些測試都是團隊中的開發人員做的，也就是透過程式碼實現的。
綜合起來就是說，團隊成員中不再有全職的測試人員，但是人人都在做測試。質量意識成為了大家的一種職業習慣，也體現在一個個活的測試用例中。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31558019/viewspace-2773047/，如需轉載，請註明出處，否則將追究法律責任。
