測試角色在項目各階段的項目管理Tips
作者：京東物流 宋雪薇
1 前言
項目管理是一個繁雜的過程，每個階段需要涉及到不同人員、資源的協調配合。每個角色都有自己的定位和任務，為了緊密配合項目經理或無分配項目經理運行項目的場景下確保項目成員共同達成項目目標，不同的角色掌握相應的項目管理意識就尤為重要。
那么，測試角色作為項目交付的質量把控者，具備相應的項目管理意識在項目的高質量、高效率交付目標上有著重要作用，如前置識別質量風險、進度風險等。本文旨在梳理、談論測試角色在項目各階段如何評估測試范圍及風險、前置暴露問題以及推進測試進度等項目管理事項，高效協作及交付測試角色產物，最終與項目各方共同推進達到高質量、高效率交付的目標。
2 現狀及思考
在現有敏捷迭代快速交付模式下，針對某一需求/項目會拆分至各個團隊，各個團隊節奏及交付目標不完全一致，且無項目經理角色跟蹤推進的情況下，存在后置與協作團隊溝通確認事項，如：未拉齊依賴方排期、前期未識別出改動系統、需求/設計變更未及時同步相關方、無設計方案溝通導致提測內容不滿足提測標準，等均可影響交付節奏。那么作為測試角色的我們可以做哪些事情？
核心主旨：高效溝通協作，提前思考后續階段較容易影響進度、質量問題及風險點，暴露問題，前置溝通、評估及推進相關事宜；避免問題后置暴露在測試階段；下一章節就讓我們來詳談各個階段測試角色可提前關注事項，與各方高效協作共同推進解決的相關tips。
3 詳談測試介入各階段的項目管理tips
3.1 需求評審階段
軟件測試的第一步就是需求評審，只有對軟件需求做了準確、完整的評審后，才能對接下來各種測試工作的開展做好基礎，如需求評審理解偏差，后期很多測試任務都將會受到影響。
需求評審完成需了解哪些信息：
- 優先級——識別項目/需求重點程度，優先級，以及期望上線時間情況（定位后續跟進力度）
- 需求背景——該需求基于什么業務背景改造（便于需求理解不偏差及后續測試階段重點關注的核心目標）
- 改動范圍——評審改動范圍基于現有系統是否有沖突、是否明確合理，是否影響其他系統，也可關注下體驗問題（避免后續開發測試階段流程不通返工）
- 識別改動/交互系統——明確該需求是否涉及其他系統改動，識別改動系統/是否需配合聯調系統（識別改動系統前置協調拉齊相關系統周期，避免后續階段臨時協調資源情況）
- 測試節點——軟件需要進行哪些方面的測試，如功能測試、聯調測試、回歸測試、性能測試、穩定性測試、兼容性測試、安全測試等
- 測試環境——明確交互系統是否支持測試環境聯調（可前置協調/前置確定聯調方案，避免后置溝通確定環境占用測試周期）
- 測試數據——根據改動范圍思考測試數據來源，識別是否可內部閉環造數，是否可使用測試小工具
- 測試方式——可前置思考使用功能測試、自動化測試
- 測試人員——識別測試干系人、明確主測試方（如重點項目/需求需要主測試情況）
3.2 設計評審階段
設計評審為評價設計滿足質量要求的能力，識別問題及提出解決辦法。設計過程中越早增加質量保證活動對最終設計效果的影響就越明顯。目前較大項目/邏輯較復雜需求/研發優化，均需研發輸出設計評審文檔并邀請測試參與涉及評審。
設計評審時需要check的內容：
- 設計思路滿足需求——結合需求背景及內容優先關注設計思路是否與需求評審階段理解的有偏差
- 設計內容是否存在遺漏——評估是否存在遺漏功能
- 關注實現方式——實時、異步等處理方式對后續測試排期、方式及測試難度有參考價值
- 評估改動設計影響——基于原有系統改動除本次需求修改內容是否影響原有功能，是需明確影響范圍，研發側輸出影響范圍
- 明確階段范圍——根據需求是否存在拆解階段交付，是需明確各階段交付內容
- 交互方/依賴方實現方式——關注交互方/依賴方實現方式
- UAT/灰度/上線方案——根據上線特性，前置溝通UAT/灰度/上線方案
3.3 排期階段
排期階段是項目管理中重要的一環，時常在此階段會暴露一些風險，排期容易出現兩個問題，一是排期不合理，二是后續不能按照排期穩步推進，好的排期就要盡量避免這兩個問題，那么測試階段合理的排期就需盡可能多的參考該節點及之前節點項目各方提供的有效信息，全局評估、拆分任務交付，最終提供較合理排期。
輸出測試排期需要考慮的維度：
- 參考項目重點程度、優先級——是否優先級與已排期需求沖突，需參考優先級調整資源及排期
- 結合需求、設計參考及核對研發工時及排期、階段交付內容——研發提供拆解后的任務排期是否合理（前置功能是否提前交付，依賴的任務是否有序等），測試依據研發排期時間提供可并行/串行等較合理的測試排期
- 關注研發是否有聯調排期——需保障提測質量，時間緊任務重情況下是否壓縮研發聯調排期，可能影響提測質量及測試交付時間
- 測試聯調排期——測試輸出聯調周期需拉齊對接系統排期（可協同產品溝通拉齊），避免臨時協調聯調時間導致延期
- APP排期——需確認實現方式為：原生/flutter
- 明確方案是否存在變更——可再次明確需求/設計方案是否存在變更未同步情況
- 明確主測試方——如涉及多方系統，排期階段可明確主產品、主研發、主測試方
3.4 測試用例編寫、評審階段
測試用例的編寫必須依據需求文檔，結合設計方案，確認所有以疑問點，覆蓋所有功能需求點，跟進需求情況輸出冒煙測試用例、功能測試用例、聯調測試用例，思考業務實操場景，模擬用戶場景串聯流程保障測試內容的高覆蓋。并在用例評審節點邀請產研參與評審，有序進行用例評審，確認疑問共同完善測試點并會后輸出評審會議紀要。
測試用例編寫、評審階段需要注意的事項：
- 確認需求文檔版本及標準——明確最新PRD版本（存在產研線下溝通后未同步測試情況，盡量避免），如有原型需明確原型及PRD內容描述不一致情況下如何開展測試工作
- 思考細節邏輯合理性及歧義描述——思考細節邏輯描述是否合理，PRD描述存在歧義點需標注明確
- 包含充分的異常測試用例——豐富異常用例，避免異常情況下功能異常
- 識別用戶體驗問題——提示信息是否明確、頁面功能是否易用
- 業務范圍和系統設計維度補全用例——跟進需求及設計細化測試維度豐富測試用例
- 測試數據、賬號、配置等——識別測試數據、賬號及配置是否需協同方配合，是否可使用工具等提升效率，如需全流程連通在該階段記錄
- 測試用例評審——與產研側確認測試范圍、溝通疑問，評審用例設計的清晰度與合理性，優先級排定是否合理，是否覆蓋了需求上所有測試點，用例是否具有很好的可執行性，用例的冗余處理機制，是否設計了充足的異常測試用例，是否從用戶的角度出發來設計用戶使用場景和使用流程的測試用例，是否簡潔、復用性強。
- 聯調用例評審——輸出交互場景與交互方評審，如為主測試，評審前串聯整個項目/需求的流程場景用例，組織評審、明確測試數據、賬號、配置等信息
- 用例評審會議紀要——記錄待確認點及已確認點
3.5 編碼階段
編碼階段作為研發角色活動，通過編碼過程來實現產品需求，此階段的異常等需相關方知悉；
研發階段需同步的信息：
- 需求/方案變更——是否存在需求/方案變更，是否及時同步至產品、測試側
- 是否有提測延期風險——存在延期風險會壓縮后續測試周期，需前置識別并拋出
3.6 代碼評審階段
代碼評審是研發全流程的工程實踐之一，通過代碼評審可以更好的保障產品質量和代碼質量；可根據改動大小與研發側溝通進行線上/線下等評審方式參與。
代碼評審階段需檢驗的標準：
- 慢sql、空指針等——可有意識評審慢sql、空指針等問題
- 業務邏輯——測試人員需關注是否有明顯的邏輯錯誤，改動是否遵循業務邏輯
- 補全回歸用例——跟進改動范圍可識別需改動影響原有功能部分，特別注意需確保主流程是否影響，補充回歸用例
- 文檔——提供新接口/修改接口是否有相應的接口文檔更新維護
- 需求沖突識別——關注改動范圍，識別其他需求是否也存在改動該段代碼問題，避免需求沖突
- 提高個人代碼評審能力——學習研發針對代碼評審的意見/建議以及好的代碼實現邏輯，便于問題更早的發現（以及代碼編寫規范、可讀性、可維護性等）
3.7 冒煙測試階段
冒煙測試是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性，盡早發現較阻塞進度問題，提前識別。
冒煙測試階段重點關注的維度：
- 基本功能驗證——優先驗證基本功能是否可用，便于后續邏輯等較復雜功能開展
- 主流程驗證——優先識別主流程問題，避免流程阻塞，阻礙測試進度，提前暴露流程問題及風險（方式依據項目/需求情況有效采取手工/自動化方式進行）
3.8 功能測試階段（內部測試階段）
功能測試階段開始了大規模的測試工作，在此期間仔細詳盡的測試，
功能測試階段核心把控的思想：
- 明確變更同步——針對測試階段任何變更需同步至相關方，避免一方不知情
- 識別需求沖突——共同測試需求，測試分支、需求相互影響
- 測試數據高效使用——分析測試數據是否可驗證多用例，高效使用測試數據驗證盡可能多用例提升效率
- 測試問題務必拋出——測試階段發現的問題即使較小也需要拋出來提供給相關確認方確認，如無需更改則記錄相關結論
- 探索性測試——探索性測試，可在測試階段發現前期未識別到的影響功能等
- 測試進度報告、風險拋出——針對時間較長/較大需求、項目發送測試進度報告，暴露風險（識別是否有影響進度、質量等風險問題，拋出問題，記錄待確認問題及已溝通確認問題
3.9 聯調測試階段（包含研發聯調、測試聯調）
聯調測試為了保障該需求/項目的所有改動場景下發的數據在全鏈路系統下正常流轉閉環，覆蓋用戶真實實操場景來確保項目/需求的交付質量。
聯調測試階段注重：
- 研發聯調環節——再次核對涉及系統交互需求/項目，研發聯調工作是否覆蓋主流程測試點
- 聯調場景驗證——與全鏈路系統進行聯調測試驗證，覆蓋用戶真實實操場景
- 補全聯調場景——在聯調階段，可能存在場景覆蓋不全情況，可有選擇性了解上下游系統邏輯，可覆蓋補全聯調場景，且針對接口及消息盡量全的確保數據傳輸場景
3.10 穩定性測試（適用于APP）
為保障APP端用戶體驗，APP穩定性測試不可或缺，上線前針對上線版本進行穩定性測試已加入到APP測試流程中，日常針對APP穩定性隨機測試也持續監控。
穩定性測試需監控：
- 崩潰率——監控阿凡達平臺統計，分析APP線上崩潰原因，豐富穩定性測試腳本
- CPU實時監控——記錄穩定性測試期間對應版本的CPU占用數據，平均值、最大值
- 內存實時監控——記錄穩定性測試期間對應版本內存占用數據，平均值、最大值
- 網絡實時監控——記錄穩定性測試期間對應版本流量占用數據，平均值、最大值
3.11 UAT階段
UAT階段主要為業務驗收階段，用戶角色驗收產研測交付內容，為確保UAT順利進行，較大項目/需求測試人員有針對性進行主流程拉通測試可提前發現配置、環境因素所產生的問題，此環節可加快UAT進度確保項目更高效交付（該階段可根據項目訴求調整）。
UAT階段應保障：
- 拉通主流程——根據項目/需求大小確定是否需拉通UAT，避免UAT因配置/環境等原因產生流程阻塞
- 跟進/復盤UAT問題——針對較大項目/需求跟進及復盤UAT中產生的問題，規避重復問題產生事項
3.12 上線前master回歸測試階段
上線前master回歸未確保長時間需求不上線分支及版本沖突等因素，上線當前進行master回歸操作可有效確保發布內容運行穩定，保障質量。
master回歸階段需check：
- master回歸測試——回歸上線功能主流程以及原有流程主流程，規避測試分支與上線分支代碼沖突等問題
4 暴露風險最終與協作方共同確定運作策略
在項目各環節已前置思考可能帶來的風險，提前規避、提前暴露，但并不能完全保障，那么在暴露風險后，可參考風險程度分析與分類定位，與項目各方高效協作，共同商榷解除風險的可行性方案以及后續運行策略。
4.1 風險程度分析
- 極小：沒有危害或微小危害 20%
- 輕度：輕度危害 40%
- 中度：中等 60%
- 重度：較大危害 80%
- 極大：重度危害 100%
4.2 風險識別分類/分解結構
- 技術類：明確是否為需求/技術層面引起的風險
- 組織類：明確是否為項目依賴關系、資源等原因引起的風險
- 外部：明確外部影響具體原因
4.3 與協作方共同商榷風險推進方案
測試人員可根據測試角度定位風險優先級，優先解決風險程度較高問題，且優先級較高風險需同步至上級知悉，必要時可采取升級等方式處理；
- 如為技術類風險——與項目經理、產品、研發共同評估技術層面解除方案；
- 如為組織類風險——與項目經理、產品、研發共同協同調整計劃/申請資源等方式處理；
- 如為外部風險——測試人員需提供具體問題，協同項目經理、產品溝通具體原因，采取相對應的應對措施；
4.4 舉例說明
4.4.1 舉例一
背景：管理工作臺項目（優先級top1，交付時間緊，開發工作量大）產生問題：因測試周期時間緊，為避免延期提測，測試在研發階段明確提測時間時，發現提測存在延期風險
- 風險程度分析及分類：組織類-重度風險
（識別階段：研發階段，識別及反饋角色：測試人員，類型：進度類） - 與協作方商榷推進方案（解決過程及方案）：
因項目優先級較高，測試人員將此風險反饋至主產品及產品負責人處，因各方前期了解的信息存在差異化/關注點不一致等，線下拉齊會議溝通，根據交付優先級拆解交付內容，迭代提測進行測試，最終拉齊前、后端研發、測試交付目標一致，并調配資源進行各項任務交付，風險解除。
小結：依據風險程度，可內部解除的快速推進落地，需耗時較長/協調資源等需及時反饋至上級溝通，確保風險盡快解除落地。
5 總結
前置評估、高效協作
保障在前置階段通過測試經驗總結提前思考后續階段會帶來的影響，包含但不僅限于：信息不同步、影響范圍不明確、依賴關系不清晰等，前置有意識的識別較容易影響進度、質量問題及風險點，并暴露問題，繼而與相關協作方高效協作、評估及推進風險點解除，避免問題后置暴露在測試階段甚至交付上線階段。
