關於軟體測試的幾點反思-關於測試團隊的組織

　這一篇是系列文章的第三篇，前面兩篇分別談了測試的必需性《關於軟體測試的幾點反思 – 測試是必需的嗎？》，以及測試工作的一些內容《關於軟體測試的幾點反思 – 測試工作的三個階段》，接下來想聊一下測試團隊的組織。
　　要討論這個話題，首先要討論下測試人員本身的歸屬，因為通常是人多了才有組織的必要，很多東西都是一點點長出來的。
　　我在讀研期間實習的一家公司，根本沒有專職的測試人員，回頭想想當時還是挺大膽的，因為做的是比較核心的系統，而且當時像我這種實習生都寫了很多核心的涉及金額計算的程式碼，然後大家自測下就上線了。這種情況也持續了好久，也驗證了不一定必需，在特定的情況下。
　　個人的工作經歷，沒有一開始去很小的研發組織。後面工作後的面試中，也接觸過很多規模較小的公司的測試人員，這種情況下大部分是直接歸屬到專案，彙報給開發經理。人數少，大部分是比較基礎的黑盒測試，相對也比較弱勢。沒有任何貶低的意思，但是客觀來說，這個階段的測試很難有一些比較深入的測試技術上的實踐，時間不允許，也處於沒有人帶的情況，大家基本上都專注在專案的功能測試上面。一直覺得環境對人的影響是比較大的。有些比較有上進心的同學會自己學一些技術，但是因為沒有指導，也沒有實際應用的場景，通常比較淺。
　　後面等到整個研發體系發展大了之後，可能測試人員也慢慢多了起來，同時服務於多個開發小組，於是就出現了測試團隊的二級組織。比如對口每個開發小組的有幾個人，或者更多，然後有一個lead或者first line manager，然後這些人彙總到一個second line的manager。這個時候隨著測試團隊規模的壯大，當然也是隨著整個研發組織的壯大，以及業務和開發方面提出了更多更高的質量要求，測試團隊在客觀上有了進一步提升的需求。主觀上因為second line的出現，會不再滿足於完成基本的測試工作，也有提升的動力。一些測試的規範，用例設計，缺陷管理，資料的分析，工具平臺的引入，自動化的開展等慢慢開始引入。
　　接下來，可能到研發部門層面有一個完整的測試團隊，進而可能是整個公司，或者事業部（BG，BU）層面有一個完整的測試部門，或者中心。
　　目前看到的騰訊和阿里的幾個大的業務導向的事業部都是這樣的情況，比如騰訊的網際網路，互動娛樂，電商（曾經）；阿里的淘寶，天貓和支付寶，都是在事業部層面有一個完整的測試團隊。
　　進一步，如果這類很大型的公司，把全集團的測試集中到一起的還沒看到，主要是因為組織架構的頂層還是按業務來劃分的，比如事業部制。
　　基於上面的討論，我們可以從測試的集中這種角度來看看測試團隊的情況，這樣劃分就有兩種，集中還是不集中。
　　集中的例子就是上面說的情況，所有專職測試人員都在一個小組，一個大的二級組，進而一箇中心，一個部門，資料結構上是一顆樹。非集中的情況就是測試人員散落在不同的開發中心，或者開發組，是一個森林。每一塊的測試人員組成一個小組，彙報給開發中心的總監，或者開發經理。 目前瞭解到不少公司是這樣來組織的。
　　每一種組織方式都是結合了公司的實際情況和要求，但是如果單純從測試團隊的價值和效率方面，目前來看，會覺得集中到一起是個更好的方式，主要的理由是下面幾點。
　　1. 集中到一起之後，因為資源的整合，可以減少各個團隊的重複建設，集中來做一些平臺建設，技術研究，或者橫行的技術共享，有利於提升團隊的技術深度。
　　2. 從業務的角度，集中後測試可以橫向的對齊，來看各個專案的質量情況，研發流程的過程執行和效率的情況。從整個組織的角度，對研發的質量和效率有促進的作用。
　　3. 從測試人員個人發展的角度，因為整個測試組織有了更好的深度，個人發展的空間也會更大，無論技術還是管理方面。
　　4. 測試人員的歸屬感，有自己的部門和自己的職業發展通道。
　　談到和專案的對應，目前採用測試集中方面的團隊也基本上是矩陣式管理，特別是針對負責業務測試的小組。一方面，從組織架構上是歸屬於質量部或者質量中心，但是從日常工作上，是歸屬到專案或者產品，和對應的產品、開發團隊密切配合，包括座位可能都在一起。
　　就目前觀察的情況來看，這種組織架構相對是比較成熟，也比較普遍被採用的，運作起來也還比較順暢。

　第二個方面，想討論一下測試人員的內部細分。IT行業早已經是內部就開始隔行如隔山，分得非常細了。考慮對口的產品和技術形態，測試人員也有很大的差異了，比如測試通訊裝置的，測試Web網站的，以及測試app的，其背景知識，工作流程也有很大的差異。即使不考慮這方面，從專注的測試工作內容上看，也有進一步的細分。我接觸到的會分為四個方面：
　　1. 業務測試
　　這一部分的測試人員就是上面提到的矩陣式管理的那一類，負責具體的產品的測試和質量提升。所以這一類的人就數量上來說通常是最多的。
　　2. 專項測試
　　如果測試組織稍大，對測試的深度有更高的要求，而有些測試型別又需要比較長時間的積累，且技能有橫向的共用性，那麼就可能有專人來做，俗稱專項。比如安全測試，效能測試等。就實際運作的情況來看，像安全測試這種看起來確實比較有必要，因為沒有長時間專注的積累難以有效果。這樣的專項測試通常人數不是很多。
　　3. 質量管理
　　有些地方叫QA或者SQA，就是第二篇裡面提到的專注在質量資料的收集，研發流程的管理和推動等事項上面的一些人。通常放在測試部門，但是也可能放在研發管理等團隊。
　　4. 測試開發
　　當整個測試的團隊比較大，需要很多共性的基礎的平臺和工具建設，就可能會抽出一個團隊專門來做這方面的事情，稱之為測試開發。
　　實際中，關於業務測試和測試開發，其實有時候界限是沒有那麼清楚的，取決於多個方面的因素：
　　1. 老大觀念
　　沒辦法，這個很重要。接觸到幾位部門級測試團隊的負責人，觀念不完全一樣，有些認為獨立的測試開發團隊很重要，且願意大的投入，有些覺得沒必要有專門的測試開發團隊，業務測試團隊應該有能力來做測試技術方面的事情。
　　2. 業務測試團隊的能力
　　這個要看實際的情況，業務測試如果要做得比較好，業務測試的團隊本身也需要比較好的技術能力，所以很多測試開發意義上的事情業務測試團隊也可以做，實際也在做。但是也有些情況，業務測試團隊本身的技術能力不夠，或者時間非常的侷限。從業務測試團隊本身的意願上，肯定也希望能做一些技術方面的事情。
　　3. 測試開發團隊和業務測試團隊的雙向互動的情況
　　一方面是看測試開發團隊做的東西能否在業務測試團隊落地，涉及方案本身，是否貼合專案時間，以及和業務測試團隊的配合的情況。這個實際情況應該還是比較複雜的，各個團隊面臨的實際情況都不太一樣。
　　最後想討論下關於測試人員外包。這裡不討論整個專案的測試外包，那是另一個範疇，也曾經和一個資深的測試leader深入聊過，不過最終也只是些理論推導，沒有實際的應用，很多問題也不好說。
　　自己關於外包的觀念也一直在變，因為看到身邊不同的實際的例子，目前的想法大致如下：
　　1. 覺得外包非常的有幫助，能幫助完成很多的測試工作，在招聘速度上也很有優勢，所以是個不錯的選擇。
　　2. 就實際運作來看，覺得外包的比例不能太高，一個正式配1-2個外包應該效果還不錯，太多了對專案，對外包同學的成長覺得都不太好。
　　在我們團隊的應用中，還有幾個小的例項的體會
　　1. 像面試正式員工一樣面試外包
　　如果我們覺得外包只是過來做黑盒的手工測試，隨便找幾個人就好了，可能效果不會太好，因為最終還是取決於人。我們目前的幾位外包同學都是我們非常認真的面試過，從很多位中挑選出來的，在團隊裡面發揮的作用其實已經超出了我們的預期。
　　2. 更放手讓他去做
　　就目前專案的情況，我們的外包同學除了做好基本的黑盒手工測試，他們也可以牽頭一個專案的測試跟進發週報，自動化的用例製作和問題定位，crash問題的跟進分析等，而且工作的態度和主動性非常好。因為我們沒有給他們設明確的界限，只要他願意嘗試，也具備基本的能力，那就可以去做。這個和上面的1也有關係。
　　3. 關注外包同學的發展
　　這兩年接觸了很多外包同學，團隊裡有好幾位正式同學也是之前做過外包，所以對外包的看法有些不同了，在職業發展上儘量和正式同學一樣看待，並關注他們個人的發展。
　　在這個充斥著企業文化，價值觀的年代，測試如果作為一個獨立的部門，也一定會被問這樣的問題：作為一個獨立的測試部門，我們的核心價值是什麼？
　　這個問題好像一直都會在，值得去想想看。
最新內容請見作者的GitHub頁：http://qaseven.github.io/