測試管理FAQ二。
1、 人員流動好嗎？ 首先注意人員流動和人才流失的區別。人才流失是一定要控制的，當然如何評判是不是人才這是門學問，有道是千里馬常有而伯樂不常有，本文不展開此問題。而正常的人員流動是很有必要的，吐故納新并不一定是壞事，所以我們才有輪崗才有末位淘汰。我想任何老板都不希望自己團隊成為養老部門。 測試工程師有別于其他技術人員的一個明顯點是對于技術廣度的掌握，這是工作性質所決定，必須先了解待測產品的各種背景才能正常開展測試活動。有鑒于此，我們應該多鼓勵測試人員的流動，也可以進行更多的虛線管理。核心思想，我們不用過多關注工作到底是由誰來完成，應更關注我們有哪些工作這些工作有沒有被完成。
用個簡單的圖形描述下，看著有點像工單系統：
對于測試團隊來說，人員流動除了傳統的輪崗、轉崗等等之外，更需要的是模糊開發與測試的界限，也就是說不僅僅是人的流動，更多的是工作內容的流動。我們不能只著眼于傳統測試工作的范圍，更要站在整個質量管理的角度看待問題。我們并非鼓動測試去做開發的工作去和開發比拼技能，而是測試本就具備這樣的能力，說白了就是復合型，反之開發也亦然。個人認為未來技術團隊里不會專門區分開發、測試的工作，或許在某一領域有偏重，但整體上的職位名稱應該是——開發測試工程師。
2、 何種團隊氛圍最好？ 很多主管喜歡打感情牌，喜歡把團隊氛圍營造成親人朋友一般，吃飯要在一起活動要在一起差點上廁所也要在一起，大家一起放聲歌唱我們是相親相愛的一家人。我想問一句，你真的想傳遞公司就是我的家這種思想嗎？你真的想把團隊氛圍打造成家庭氛圍嗎？先不說能否做到，做到之后會有什么弊端考慮過嗎？家人之間的相處之道和同事之間的有何不同？這還用問嗎？ 順帶說下腐敗。組織活動是難，眾口難調，在一定程度上強制所有人服從命令聽指揮我覺得一點問題沒有。但是，一面強制他人一面還要求他人能發自內心的支持并且玩的興高采烈，你覺得可能嗎？ 不少人認為高凝聚力團隊的氛圍是最好的，這點大致沒錯。高凝聚力可以解決很多問題，什么戰斗力影響力學習氛圍互幫互助，特別是臟活累活苦活有人干，關鍵時刻也有人挺身而出。但高凝聚力的形成有個充要條件，主管一定是核心。換言之，主管離開會對團隊的損傷很大，這點風險太高。如何彌補呢？在此之上應該是什么呢？ 團隊中30％的骨干人員有豐富的工作經驗，較強的工作能力，并對團隊有極高的忠誠度；團隊中有正常的人員流動，不斷的有新鮮血液補充保持團隊活力，有發泄負面情緒的正常渠道，在工作中能持續保持激情；團隊中上行下效，令行禁止，謀議資于眾人，決斷歸于一將，信息及時共享并盡可能透明，保證較高的公平公正；還有最最重要的，測試人員一般都有點自卑感，認為測試不如開發，某種程度上講這話沒錯，團隊能讓測試人員直視此問題，不用委曲求全自怨自艾，更不用做過多的事情來刻意表明測試并不比開發差，自謙過頭就是自傲，自傲過頭就是自卑，牢記這點。 這是一種什么團隊？這是一種什么氛圍？成熟的團隊，成熟的氛圍。我們需要為團隊打造一種綿綿然而富有激情的氛圍，真的勇士敢于直面慘淡的人生敢于正視淋漓的鮮血，心里素質不過硬內心不夠強大能指望著打硬仗嗎？遇到點挫折就怨天尤人摔倒了就爬不起來，即使能力再強要你何用？這世界天才是少，但大家就更少，有多少天才在成為大家的路上就早早夭折了？我們需要心智成熟的團員，組成素質過硬的團隊，簡單講，我們要組建熟男熟女的團隊，而不是幼齒團隊。注意，這與年齡無關，白活幾十年的人多了去了。在互聯網企業，在年青人較多的團隊，活力肯定有，同時浮躁也難免，所以營造成熟的團隊氛圍就顯得更加重要。至于如何一步步的建立并最終達到此目標，因篇幅所限故本文不做探討，有興趣的可私下找我。最后，現在知道為什么很多人叫我大叔了嗎？還不知道開扁的啊。
3、 如何考核測試人員？ 這問題有太多人探討，網上隨便一搜一大把。大致匯總有以下幾點： l 按業績：又可分為按結果和按過程。按結果就是待測產品最終質量如何，上線有多少故障；按過程就是針對測試過程中的各項產出進行評判，什么有多少測試用例多少缺陷多少腳本用了多少資源多長時間等等等等。 l 按能力：會不會編碼寫腳本會不會開發測試工具會不會各種類型的測試會不會寫文章會不會演講反正上天入地電光霹靂有你不會的沒。 簡單粗暴點的按結果居多，管你三七二十一線上有多少故障，超出預訂目標就砍你。復雜點的把各種指標放一起加減乘除還要加上各種權重。 無論哪種都有個核心問題，如何收集數據？特別是準確的收集？所以想要公平客觀的考核測試人員首先必須拿到準確的評估數據，這也是為什么我一直強調測試數據報表重要性的原因。當然，測試報表的作用遠遠不止用于考核，更多是為制定未來測試發展方向所用，最近我一直在整理我們需要哪些報表怎樣的算法才更精準，本文不做深入探討，有興趣的單獨找我。 有些數據可以收集但有些數據需要主觀判斷，尤其是綜合素質方面，難以量化。所以我認為考核的思路應該是一個中心兩個基本點，以產品建設的最終結果為中心，堅持高效的研發過程，堅持小規模作戰的思想。 產品發布后是否達到預訂目標甚至超過預期，這是我們最關注的，你測試做的再好任你說的天花亂墜，最終產品目標沒達成那就是扯淡。所以我反復強調不要僅站在測試的角度看問題，要不得。 互聯網產品出故障不可怕，可怕的是故障遲遲得不到修復。出個P1故障我一秒甚至是一毫秒就修復了，影響能有多大？此觀點很多人論述過了在這我不重復。所以在產品建設的過程中，我們第一考慮的是高效，如何才能高效，凡是阻擋高效的一律掃除。天下武功無堅不摧唯快不破，測試工作如何能更快的進行完，這是我們優先考慮的。 不要把團隊無限制的擴大，更不要認為人多就好辦事。咱們國家為啥要搞計劃生育？用最少的人辦更多的事，這才是王道。當然，出于某些個人利益考慮而做出的選擇請無視我說的。 綜上所述，考核測試人員就三條：產品建設最終結果如何，測試過程有沒有更快，測試資源有沒有更少。
4、 測試人員如何才能晉升？ 這問題太敏感，不適合公開講，我做過幾次試驗，還算有點心得，改天單獨寫個攻略，私下傳閱。不過有一點是可以說的，想想你所在的企業，所在的團隊，你的老板，過去現在將來需要什么樣的測試人員，你可以列個表格一一對比，如果看不清未來那就不必費力了，模仿別人的道路往前走吧。
5、 垂直團隊與傳統團隊有何區別？ 垂直化的測試團隊與傳統結構的測試團隊有何區別？看完這么多FAQ你還不清楚那我也沒辦法了，傳統結構的測試團隊基本不會這么做。 垂直化測試團隊有個瓶頸，資源較少，測試人員的發展空間容易受限，特別是往管理方向發展的測試人員。所以不管是縱向還是橫向發展，最好是走技術與業務相結合這條路，這也是我們一直說的，跳出測試的條條框框，站在垂直的層面看問題。 至于是垂直結構好，還是傳統結構好，仁者見仁智者見智吧。