導語

相信每一位測試小夥伴對於測試過程管理都有自己的獨特見解。我所在的部門2017年初開始施行測試變革——“測試左移”。過程中有從技術層面的”左移“，也有從流程層面的”左移“等等，方式形態萬千。今天和大家分享的是我在這個過程中，除了個人技術能力提升外，在測試過程管理上的一些感觸。它讓我目前作為業務測試負責人也算得心應手。希望對其他小夥伴也有一些借鑑。

年後，我負責的業務測試內容發生了一些變化，說實話，當時內心還是感受到一些慌亂。現在總算是風雨過去，再見彩虹。而在這個過程中有兩個關鍵點讓我的測試過程管理工作受益匪淺，一是努力培養專案團隊全員的質量意識來改善過程質量，二是制定良好的測試策略來指導測試工作更清晰。

培養質量意識

我們必須承認，產品質量不是由測試同學測出來的。作為專案團隊成員，產品、開發和測試的作用都是獨一無二，不可替代的。我們都為提升產品質量一起奮鬥。然而，在實際迭代過程中，產品同學會更加關心需求的如期上線，開發同學會更加關心編碼的及時完成，導致質量工作的重擔向測試這一方偏移。我們也知道，忽視了前期的質量工作，在後期的測試環節甚至版本釋出上線後，我們需要為之前的行為買單，耗費更多的時間和精力。

在產品日益複雜化的今天，使用者需求不斷增多，我們的業務KPI壓力驟增。在如此嚴峻的環境下，如何能夠求得質量和收益的雙贏呢？“測試左移”應運而生，但施行測試左移的一個重要前提是：團隊對於質量風險前置這個認知上的一致性。我們團隊主要從以下幾個方向來努力培養團隊全體成員的質量意識：

圖1 提升團隊質量意識的五個途徑

第一， 質量宣講

首先，普及產品質量度量引數。需要知道，除了業務KPI資料，產品還存在質量資料。而且我們通過質量資料來度量每個業務的開發質量和需求質量。質量宣講能夠在團隊內普及這些度量資料的含義，明確指出核心資料會在正式場合進行彙報。對於異常的資料會標紅顯示，比如嚴重使用者反饋數、主線不通過數、交付通過率、千行程式碼缺陷率、引入原因分類（包括設計缺陷、編碼缺陷、需求缺陷等）等維度來衡量各個環節的質量以及我們產品的整體質量。

其次，部門團隊橫向對比，提升產品質量的敏感度。通過團隊間的橫向對比，以競爭和獎勵的方式來提升團隊成員對質量問題的敏感度。在桌管內部，針對嚴重使用者反饋，我們改進質量監督機制，實施研發運營質量改進積分方案；同時按業務中心進行分類，實時監控每月各業務的嚴重使用者反饋的趨勢，鼓勵從流程優化上進行了質量改進的團隊，刺激各團隊主動提升產品質量的氛圍。每半年進行一次積分排行，前三名進行獎勵，非常具有吸引力。

此外，落實專案總結，避免形式化。如何避免專案總結趨於形式化，如何敦促專案總結的方案能夠閉環落地，都是產品質量的重要保證。針對這塊，我們巧妙地發揮了PM的角色價值。如果沒有PM，測試也可以發揮自己的擔當力去推動。主要工作就是明確需要改進的內容，並形成明文規範存檔。規範一旦建立，在後續的執行過程中，如果再犯，需要明確指出，並予以相應的懲罰。比如，SVN提交程式碼需要關聯正確的需求，發現關聯錯誤必須直接打回（影響交付通過率）。

第二， 主人翁意識

團隊內部施行owner責任制，讓每一個角色都有機會感受負責人的體驗。上半年我們業務團隊，開發同學主動承擔負責人體驗。他們的責任制體現在新需求的版本迭代、crash率、使用者反饋跟進以及主線大版本合入。一般情況下，我們建議輪流交替體驗。這樣做的好處有三點：（一）可以通過實操的方式瞭解各個流程的每個細節；（二）身為owner必須對整體過程負責，包括不按時提測，bug解決不及時等問題，可以有效減少過程問題；（三）可以通過過程體驗，發現過程中存在的一些問題，後續主動去避免，培養良好的研發習慣。

第三， 產品走查

以前我們的產品走查總是在測試完成第一輪整合測試之後開展，現在發現完全沒有必要。產品同學對客戶的需求應該是最清楚明白的。如果把這個環節前置到開發提測之前，產品同學可以快速發現與需求實現不一致的地方，而且也可以將一些低階的錯誤在提測之前消滅掉，從而提升開發同學的交付質量，也減少了在後面匆忙走查導致的問題遺漏。

第四， 互相結盟

對於測試而言，和其他角色的結盟絕對是有利無弊的（切記：永遠不要和團隊小夥伴形成對立的局面）。我們可以和產品結盟，推動開發去解決體驗上的問題單，提升開發的精品意識；我們可以和開發結盟，推動產品的需求文件更加規範化，便於後續的編碼和測試分析；我們還可以和PM結盟，推動整個團隊內部流程的優化。

第五， 上層推動

想要在專案團隊內達成一個目標，團隊內領導的支援比較關鍵。它能夠推動產品實施過程中的問題解決。測試同學如果覺得自己號召力不夠，可以求助於自己的leader。

在團隊內部，小夥伴們的質量意識提升後，彼此間的溝通也變得相對簡單，而協作也相對容易執行。比如討論質量相關的資料，他們可以丟擲疑問並討論解決；在團隊內部推行一些新的研發流程的時候，產品和開發能夠積極配合，並給出可行的實踐方案。團隊內細節上的把握讓我們相信，測試工作可以逐步左移，而產品質量也能進一步提升。

制定測試策略

除了質量意識需要整個團隊共同努力外，良好的測試策略也同樣並不僅僅是測試角色的事情。我們必須承認，一個好的測試策略，絕對會讓咱們後面的測試過程少操很多的心。

當被通知成為一個業務的測試負責人之後，我想我們的腦海裡，或多或少都會去勾勒下我們將要如何把控這塊業務的測試策略。本部分主要介紹遊戲合作這個業務的測試策略設計。它主要包括全域性測試策略和具體需求的詳細測試策略。

1、全域性測試策略

全域性測試策略主要是從巨集觀上對我們的業務制定對應的測試策略。在我看來，想要從巨集觀上制定策略，必須要了解它的專案外向屬性。而外向屬性自然是包括人和產品特性，也就是團隊屬性和業務屬性。在具體分析專案外向屬性之前，我覺得首先需要對需求進行管理。因為不管是團隊的人或是產品特性，最終和測試對接的都是需求，所以我們需要首先從需求上進行管理。

（1）需求管理

這裡的需求管理主要講的是需求的合理分類。它不僅有利於專案生產率的度量，還有利於測試人員實施正確的測試策略。下圖展示了，我們的需求類別：

圖2 需求分類包括新需求、需求優化、技術需求、bug轉需求

我們的需求可以劃分為四類：新需求，技術需求、需求優化和bug轉需求。針對不同型別的需求，我們可以先制定它的巨集觀測試策略，在前期可以和開發、產品達成一致，並將其固化：

1）新需求：涉及客戶端的需求，要求開發必須提供詳細的技術方案，產品提測前進行走查，測試提供詳細的測試分析進行評審，測試過程資料需要程式碼覆蓋率支撐；而與客戶端無關的需求，不強制要求（從另一面也反映該類需求對測試人員的能力要求不高，可以交由自己培養的合作伙伴cover）。

2）技術需求：要求開發提供詳細的技術方案，測試提供詳細的測試分析，測試過程資料需要程式碼覆蓋率支撐。

3）需求優化：不同的優化點可以採用不同的方法，需求優化包括，

4）體驗上的優化：小的優化，交由合作伙伴cover，測試owner採用review的方式；

5）運營優化：優先自動化實現，若自動化無法覆蓋，需要具體分析；

6）資料上報優化：開發人員自測和測試CR完全cover；

7）Bug轉需求：由開發人員自測、測試CR和合作夥伴迴歸cover。

總體而言，技術實現上有比較大的變更時，開發人員需要提供詳細技術方案；介面表現發生比較大的變化時，產品人員需求提前進行走查；其它情況優先自動化實現，不可以自動化的培養合作伙伴進行分析外加正式員工review的方式；以上均不是，則測試負責人再發起具體分析。

（2）團隊屬性

團隊屬性主要源於研發團隊的組成、任務分工以及需求來源。一個研發團隊，必然包括開發、產品、運營和測試，部分團隊可能不存在專案經理。但是作為測試負責人，除了瞭解測試角色負責的內容，對於團隊內部的其他角色必須也要非常熟悉，包括知道人員的比例，知道他們的不同分工。比如遊戲合作專案，它的檢視關係如下：

圖3 遊戲合作團隊組成

圖3主要展示了遊戲合作專案團隊內部的組成，以及會直接和測試對接需求來源的關係圖。從上圖可見：

1）我們團隊存在1個專案經理。專案經理可以從全域性掌控專案的規劃和資源的協調。在關鍵的時候，他可以充分發揮專案經理的優勢幫助我們解決一些棘手的問題；

2）開發人員一共11人。從開發側會產生技術需求或Bug轉需求類，他們會直接對接測試人員。開發側存在分工不同。客戶端開發比較固定，需求頻繁；而web端開發負責前端頁面，屬於資源池非固定人員，因此需求相對不頻繁；

3）產品經理一共2人。從產品側會產生新需求以及需求優化，優化主要是體驗上的優化和資料上報上的優化。產品側需求直接對接開發和測試人員。

4）運營人員一共4人。從運營側會產生需求優化，但運營側存在分工不同：活動類的運營要求對接的測試人員屬於專屬活動測試人員，因此無需關心；合作類分為兩類合作，一類是談到一些新的合作方式或針對已有的合作方式做一些優化，最終轉換成需求會對接給產品經理（並非直接對接開發和測試），而另一類是將一些已有的合作方式運用到其它遊戲會直接對接需求給到推廣類；推廣類主要負責運營，他會直接對接對應的開發和測試。

乍一看，整個團隊18個人，測試只有1個人，測試開發比是1：11，亞歷山大。但瞭解團隊的組成，以及各個人員的分工後，發現並沒有想想中的嚴峻，因為實際常規開發的共7個人（6個客戶端+1個web端），1：7還是可以應付的。

從上圖，我們也知道：和測試直接對接需求的人員除了開發人員、產品經理，還有負責推廣類的運營人員。我們在進行需求溝通時，包括針對需求的排期、需求的測試策略，需要找到正確的人。

（3）業務屬性

業務屬性主要源於分析業務的需求屬性。遊戲合作的業務劃分如下圖所示：

圖4 遊戲合作業務屬性巨集觀測試策略

遊戲合作大致包括7個特性，還有1個特性是待開發的區域。開發、產品、運營人員在針對對應特性建立需求的時候，儘量按照我們的需求分類存放到需求池。對於不同類別的需求，我們首先採用該需求型別對應的巨集觀測試策略，接著針對具體的需求點再做詳細的測試分析。如果需求策略需要做出調整，對應的發起人提前說明，這樣不僅有利於測試人員進行測試分析，也有利於需求提測後可以得到及時的測試響應，避免由於測試資源緊張要依賴固定的負責人去處理對應的需求。

2、詳細測試策略

詳細測試策略，主要對具體的需求進行詳細的測試分析，制定策略。針對具體需求的詳細測試策略，每個團隊可能不一樣，在我們的團隊，測試策略設計模型如下圖所示（對這部分感興趣的，可以線下溝通）：

圖5 詳細測試策略設計模型

從左至右，依次是需求分析，開發實現分析，基於這兩點得到測試分析點。裡面有提到模型，關於測試建模可以參考我的另一篇文章《再不測試建模你就out了》。

總結

按照目前實施的遊戲合作測試過程管理方法，遊戲合作業務今年上半年的質量尚可，漏測率為0，嚴重使用者反饋為0，千行程式碼缺陷率維持在3左右，其它核心質量指標資料也無異常。還有一點需要提下，就是當日常測試工作中遇到多個需求並行的時候，我們可以使用四象限法則（通過優先順序和重要性）來排序，通過PM來幫助我們協調。在後續的測試過程中，如果團隊或業務屬性有大的變化，我們再靈活調整進行適配。原則上，整個專案可以和諧的運作，共同締造高質量的產品。

本文主要從五個途徑介紹瞭如何培養團隊的質量意識，以及如何把控業務的測試策略。文中所提到的方法，主要是基於我自身實踐感覺有價值的分享點，當然不能以偏概全。在後面的測試過程管理中，我們還需要更多的思考、實踐來豐富完善。如果你看完之後，能夠得到一些測試過程管理上啟發，它便發揮了它的價值。期望對於想要改進測試過程的你有一些幫助，也期望對於即將走上測試崗位的小鮮肉有一些幫助。

關注微信公眾號：騰訊移動品質中心TMQ，獲取更多測試乾貨！