前言

測試作為整個專案中的一環，在專案流程中起著不可或缺的作用。部分團隊是缺少專案管理角色的，這個時候，測試對專案流程的推進、專案質量的保證顯得尤為重要。好的測試，能在整個專案流程中以QA角度做好專案管理和及時的風險預警，讓專案如期上線且保障質量。業界一直強調測試前置，那麼測試在專案中，如何根據專案情況做前置工作推進專案流程，讓大家都開心工作呢？本文以自己所在的專案組為例講述專案流程中的一些事，希望可以與大家一同探討~

一、QA在專案中扮演的角色

【why】明確目標是什麼：明確做這個專案的目標是什麼，可適當根據目標對需求實現、專案質量、研發提測時間點等做一些調節。

【when】專案的deadline：考慮專案組的特殊性，我們需要知道專案需要什麼時候上線，明確專案deadline，根據時間節點制定合適的測試計劃

【what】各階段我們需要做什麼：可以重點關注專案流程中，QA參與與輸出的環節。有輸入才會有輸出，所以輸出的環節往往是需要QA花費時間去思考的地方。

【how】遇到風險點時怎麼做：測試階段，除了QA環節的風險點需要及時暴露和push外，這個階段研發和產品也在做一些工作。在專案流程管理中，作為最下游的參與者，需要關注這些風險點，及時暴露和push解決。

【who】QA、RD、PM

二、我們面臨的挑戰

2.1挑戰點

1.發版頻率在排名第二，2021全年發版71次，相當於每週都有一個版本在進行迭代，快速迭代的節奏， 對人效和團隊協同效率要求高。

2.整個2021年，研發人均bug數為123個，bug較多， 提測質量不高。為了不拉長專案週期， 保障較短的bugfix時間非常關鍵，同時要考慮如何提高提測質量。

3.整個2021年，測試人均提bug量最多，在專案節奏緊張的情況下，發現和提bug的效率必須提升。

2.2關於提測質量

針對上述挑戰的內容，我們可以看到提測質量上，我們存在不足之處。我們之前做過提高冒煙用例比例、冒煙交叉執行、時間預估增加冒煙時間等嘗試，最後發現收穫的效果有限。主要原因如下：

1. 多方合作、專案有固定deadline：由於專案特殊性，部分需求是多方合作的模式且有固定的deadline，就需要專案儘快上線，在對專案效率有極高要求的情況下，我們允許帶一些層級深的bug上線，針對上線情況做hot
   fix。
2. 專案節奏緊張，需快速迭代更新：現有研發團隊是序列的節奏，能持續高效迭代，為保證專案節奏的穩定性，避免出現因一個專案週期拉的過長導致節奏紊亂，我們接受分步提測的形式，就有可能出現冒煙功能不完整的情況，導致提測質量不如預期。

基於以上原因，我們可以看到在質量與效率之間需要做一定的選擇時，需要向專案效率傾斜，所以我們既然無法更好地改變提測質量，那就去改變我們能改變的。

三、面對這些挑戰，QA可以做什麼

QA可以做什麼讓整個迭代週期變短，在bug很多的情況下還能快速迭代且線上問題較少呢？先來看下我們的專案流程：

從整個專案流程上看，可能與很多團隊如出一轍。在流程上，QA作為下游的一個部分，可以看到QA參與輸出的內容其實有很多，這些部分就是我們可以嘗試去改變提升的點。
那麼我們從這些輸出內容看下，面對上述挑戰，QA都做了哪些改變以及還有哪些困境。

3.1專案排期計劃

專案排期計劃模板：

【when】專案排期一般是需求評審完後，根據需求拆分需求模組和開發模組。
排期計劃中，QA的工作：熟悉需求，拆分需求模組，制定測試計劃
QA同學加入進模組拆解，能更好的瞭解需求，拆分的開發模組也能更快的知道當有bug時，bug是屬於哪個端的，提給哪位對應的開發。
根據各模組的提測時間和大致開發週期，QA同學也能制定對應的測試計劃。

【what】-- QA具體需要做什麼

1. 協助開發拆分功能模組，確保模組都有對應的開發負責人
2. 確認專案deadline、開發總預計時間和提測時間

3.2測試計劃制定

專案測試計劃模板：

【when】測試計劃一般在專案排期給出後1天內提供，後續根據排期動態調整

測試計劃中，QA的工作：根據需求預估時間和人力，明確測試環境與策略，制定合理的測試計劃，預估風險

【what】-- QA具體需要做什麼

1.拆分功能模組，模組明確好對應的測試。（包含用例編寫安排、一、二輪測試安排和相容測試安排）

2.預估好專案的總體測試時間和各輪次的測試時間

3.一輪接近尾聲時，與開發明確好上預發時間；二輪接近尾聲時，與開發明確好上online環境的時間

4.如有資料配置項，二輪測試開始前與產品明確好配置所需內容和完成時間節點

以上1、2兩點儘早提供，其餘可在對應時間點給出。當然，如遇到需求變更、人力變更等需要及時提出和調整。　

【how】-- 具體怎麼做

根據開發排期，動態制定和調整合理測試的計劃。

• 根據提測時間，決定用例執行順序與分配：
  如下圖拆分的測試計劃，後臺配置（星火）與使用者端提測時間不一致，結合兩個提測時間點，我們利用使用者端提測前的時間，先執行後臺配置的用例，這樣即使是分步提測，我們也能確保每次提測時測試資源能跟上。
  
• 根據功能制定測試輪次
  對於主幹功能：需要多次執行測試用例，一般制定三輪的測試，一輪在測試環境，二輪預發環境，三輪線上環境
  對於對內的、不影響使用者使用的功能：制定一輪測試，在測試環境測一輪。比如星火等配置後臺是給運營使用的，做一輪測試，上預發後產品走查驗證+配置內容即可
  活動類的功能：依據活動的複雜程度和使用頻次，制定測試輪次。比如新年活動，是一次性的活動且活動時間緊，評估後我們在預發做了一輪測試就上線了，上線質量也一樣較好。具體測試流程：活動類測試流程嘗試
  
• 按照模組、用例量與難度劃分，制定每人每天用例執行目標
  一輪測試模組劃分根據用例編寫與熟悉度劃分
• 實行交叉測試，避免因不熟悉導致遺漏或效率降低
  二輪進測試進行交叉，利用TC平臺的任務指派，也可以清楚看到組員的任務數量與完成情況。

如下圖，測試計劃的拆解與人員分配，細緻劃分到每人每日的工作目標，且各模組的分配會進行交叉，一輪測試人員發現用例不完善或測試不方便的地方也即使提供了文件以便二輪人員儘快上手測試。

【小結】：我們可以看到，調整測試計劃的4種方式，主要目的都是通過這些辦法去更高效地去完成測試任務，保障專案如期上線；更完善、全面地去發現bug，提升專案質量。測試計劃的合理調整分配，是面對專案過程中各種挑戰的有效方式之一。

3.3jira定製化流程

1. 定製化的jira專案流程：
   

版本釋出管理三部曲：

• jira版本釋出管理：從產品建立版本開始，到最終覆盤，整個流程和資料統計都體現在jira看板中，方便統一管理
• 專案進度自動同步：如下，專案組成員能很清晰的知道當前專案進度，且版本進度每天都會自動在大群同步；完結的專案，也會根據專案情況自動同步覆盤資訊
  

【小結】：

1.定製化的流程，讓流程更加統一規範和智慧化。

2.關鍵資訊的及時同步，能減少每日站會、資訊同步會等重複會議，節約了時間。
各團隊之前的協作更加順暢，那團隊協同效率和人效也就自然而然能進一步提高。

2. QA高效提bug、研發快速修bug祕訣：

2021Q1 效率工具的需求收集提效討論中，提bug流程的優化建議一一實現了，每個人提bug 的速度大幅提升，主要彙總如下：

• bug區分問題型別 —— 使bug分類更精準，能更好地分析資料，push對應人員
• bug狀態展示優化 —— 各狀態一目瞭然，更快找到需要處理的bug
• bug描述預置版本、步驟、裝置等資訊 —— 減少重複內容輸入，提bug效率更高

• jira移動版接入使用 —— 附件內容更方便上傳，bug描述更準確，減少因無法復現、描述不清等原因帶來的重複溝通成本
  
• bug流程新增：一輪漏測、fix bug引入選項、bug描述不清的狀態 —— 當然這些指標目的不是為了追究是開發或是測試的責任，是為了分析bug，總結原因，從中找出不足的地方（比如用例設計不完善、開發修復bug未自測等問題），大家共同進步，提升專案質量，從而讓專案進行更流暢與高效。
• 自動提醒開發QAfix和驗收bug：—— 精準找到需要處理bug，處理效率大大提升
  專案流程覆盤中，我們約定p1bug當天需要fix，p2bug原則上fix週期不超過T+1天，驗收不超過T+2天。如下圖，就是根據形成的規範自動提醒研發、測試的內容：
  
  

【小結】：

1.即使是預置的一些提bug資訊和介面優化，也讓測試更“優雅”地工作，提bug和驗bug也更有勁兒了。

2.T+1修復週期的約定與訊息推送，給了研發一個心裡預期，正如我們根據專案情況調整測試策略一般，研發也根據我們給的預期調整了工作模式，從而使研發fix bug週期保障到最短，高效且有質量地修復了bug。　

工作流程的調整與滿滿預期的加持，讓整個團隊的工作效率極大提高。　　　　　　　　　　　　

3.4測試報告

1. 測試日報

【when】一般專案提測後，需要每日下班前傳送日報

【what】-- QA具體需要做什麼

彙總其他QA的進度，根據專案情況傳送日報or週報。
日報中風險項一環節可根據專案情況修改，同步計劃、提醒事項等都可以寫入。
push開發fix bug：p1 修復週期不超過T+1天，bug數量較多時，可根據測試情況適當催開發修改（比如一輪測試接近尾聲，還有很多服務端前端bug，就需要催一下了）

【how】-- 具體怎麼做

在galaxy平臺工具上，實現了日報自動生成工具，每日可自動生成日報內容，方便大家看進度，且日報中還有當前bug狀態和連結，研發也能更快找到自己的bug。
日報一鍵生成效果如下：

【小結】：

日報的自動生成，節省了測試每日彙總進度的時間，更是直接大幅減少了關鍵資訊的溝通同步成本，是人效和團隊協同效率提升的又一次加成buff。

2. 質量報告（測試報告）

【when】專案上線後，對專案進行總結梳理

【how】-- 具體怎麼做
結合jira的使用流程，可一鍵生成測試報告並同步質量平臺。

生成的測試報告示例：

3.5專案覆盤

【when】專案上線後的一週內，小型專案如有必要可合併組織

【why】覆盤的目的：針對專案中不足之處，共同討論對策，爭取下次做的更好

【what】-- QA具體需要做什麼

1.資料文件準備：形式其實不做限制，需要的資料、文件等準備好即可，也可以與開發輪流組織。

2.會議上形成的todo list需要進行跟進處理

【how】-- 具體怎麼做

覆盤例子：

覆盤提效jira看板：如下圖 — ps：催bug或者發日報的時候也可以使用，比較清晰

【小結】：定期做專案覆盤，讓團隊意識到我們當前存在的問題，推進專案流程一次比一次做的更好。

【不足】：
當然，在覆盤過程中，各團隊雖然達成一些共識共同改進，也遇到了一些列問題。

問題一：專案節奏已經很緊張的情況下，大家可能都在趕專案進度，沒有餘力去做覆盤總結工作，追求效率從而忽視了質量。

問題二：覆盤形成的todolist也沒時間去跟進，導致覆盤的總結內容最後不了了之，覆盤失去意義。

問題三：一些覆盤改進點，往往由於各種特殊原因而不能按規定執行 。

基於以上原因，覆盤收穫的效果是比較有限的，也是我們今後需要探討與改進的一個命題。

四、專案風險

4.1風險評估

專案流程中，我們關注各個階段需要做什麼事的同時也會做專案管理與把控，關注專案風險，守住deadline。

風險可以分為兩類：質量風險和進度風險

舉個例子：
用例編寫的時間不夠，影響測試時間和上線時間，我們稱之為進度風險；而用例編寫時，編寫用例人員不熟該功能，用例覆蓋不足，我們可以稱之為質量風險。

這裡我們主要關注的是專案進度，所以著重關注進度風險一項。進度風險，就是在專案進度中出現的風險從而影響了整個專案的時間點。

在測試計中，我們設計了風險一欄放於第一位，目的就是讓QA在專案流程中，及時從測試角度去觀測和記錄風險。

比如：

4.2風險對策

面對風險出現時，需要case by case討論。在進度風險出現時，首要原則就是及時暴露風險、尋找方法去儘可能降低風險。

專案組很多專案因與其他部門配合，有固定deadline並且允許有部分已知問題帶上線，那麼我們一般從測試開發角度去商議的解決辦法如下：

以上方案如果還不能守住deadline，就要考慮專案延期。

結語

上述內容是作者所在專案組結合已有的測試流程，針對專案遇到的挑戰進行流程推進以及推進後的總結介紹。
鑑於不同專案組的特殊和差異性，文中提到的方法和手段可能只是冰山一角，不一定完全適用各類專案。根據專案情況做前置工作推進專案流程，其實是一個很大的命題，不同專案組有時存在的問題也不盡相同，測試在專案流程中還能做哪些更 nice 的事，還是需要靠大家在現有情況下去進行探索和總結。也歡迎大家留言與我們交流討論~