漫談測試成長之探索——測試排期
《漫談測試成長之探索——測試文檔》一文闡述了我們可以從項目維度去整理測試相關的文檔來提升自己，本文將從測試排期方面探索成長方向。
我們知道，對於做一件事，我們要有計劃，要知道目標，要記得看時間。這裡的時間對應到軟體測試中就是與測試相關的時間節點。如圖1-1所示，在以往工作中，作為一線測試執行者，我們一般會關注開發計劃提測時間、測試計劃開始時間、測試計劃完成時間和需求計劃發布時間。但是，經驗告訴我們，只關注這些時間節點似乎是不夠的。在實際工作中，需求實際可測試的時間經常延期，測試時間被壓縮的情況時有發生。
那我們能做些什麼去規避或者說減少測試工期被壓縮的情況呢？本文的答案是：「作為測試工程師，除了關注測試執行相關的時間節點外，我們也需要關注和跟蹤項目維度的所有關鍵時間節點。」
一、探索型測試排期
如圖1-2所示，在探索型測試排期中，我們需要關注的時間節點增加到14個，包括需求計劃評審時間、研發方案計劃評審時間、開發計劃開始時間、開發計劃提測時間、測試計劃開始時間、測試計劃完成時間和需求計劃發布時間7個計劃時間節點，同時包括以上七個節點的實際完成時間節點，共14個節點。實際工作中，計劃時間節點和實際完成節點很多情況下都會不一致，且大多數情況實際情況會晚於計劃的時間，這裡簡化為一致標記在一個時間節點上。
為什麼需要增加自己的工作量去關注和跟蹤這些時間點呢？
首先，在討論做這件事的意義前，我們先分享下不做這件事可能的後果。對於一個需求或者一個項目來說，項目的發布時間一般是不能延期的，如果開始測試前的任何一個時間節點發生延期，最後為了保證項目按時上線，只能壓縮測試的時間。這樣的後果就是測試只能加班，並且，如果由於測試時間被壓縮導致測試不充分從而引起的線上事故還是得由測試人員承擔事故責任。
其次，我們來討論下做這件事的成本。做這件事的成本並不高，我們只需花幾分鐘的時間提前諮詢下相關負責人的計劃完成時間和每天的進度，並整理好各個時間節點計劃時間點和實際進度後，同步給項目群。
最後，我們再來討論做這件事的意義。一方面，如圖1-3，項目過程中一旦有前置時間節點出現延期情況，我們就可以提前識別和暴露風險。另一方面，從項目維度識別和跟蹤各個節點的進度，不僅可以提升我們對項目整體的認知，也可以逐步提升測試人員在團隊中的影響力和話語權。
二、總結
為了保障項目按時按質發布上線，也為了讓我們自己按時下班還能不斷成長，我們應該學會整理和跟蹤探索型測試排期。如果項目中有項目經理或者其他人擔任起每個需求進度的跟蹤工作，那你就可以花更多的精力去提升自己的其他方面，如果項目中並沒有人對你負責的需求進度進行跟蹤，那你就要承擔起這個工作。因為做這件事並不難，還能幫助你成長。
作者簡介：Chaofan，愛測角成員之一，專註探索和分享軟體品質保障。
如果需要上文探索型測試排期模版文件，可以瀏覽原文獲取。
原文地址：《漫談測試成長之探索——測試排期》
相關引文：《漫談測試成長之探索——測試文檔》
