測試在項目流程中的那些事兒

語言: CN / TW / HK

前言

測試作為整個項目中的一環,在項目流程中起着不可或缺的作用。部分團隊是缺少項目管理角色的,這個時候,測試對項目流程的推進、項目質量的保證顯得尤為重要。好的測試,能在整個項目流程中以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.關鍵信息的及時同步,能減少每日站會、信息同步會等重複會議,節約了時間。 各團隊之前的協作更加順暢,那團隊協同效率和人效也就自然而然能進一步提高。

  1. QA高效提bug、研發快速修bug祕訣:

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

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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-jr4sSSa1-1647325340880)(http://pfp.ps.netease.com/kmspvt/file/6229b793cd05488340940b7dYcR67yhq01?sign=gL7e5CD91maZDjs7XkFpJTX3Oa4=&expire=1646902939)]

  • 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。

  1. 質量報告(測試報告)

【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 的事,還是需要靠大家在現有情況下去進行探索和總結。也歡迎大家留言與我們交流討論~