概述
在互聯網產品中，產品的迭代速度越來越快，項目中的測試同學面臨着前期需求搖擺不定，中間各種開發進度死鎖，而發佈時間卻無法推遲。項目的前期階段似乎總是在壓榨着測試的執行時間。
如何減少測試返工，測試階段的工作量的同時，保障項目質量？
立項後
項目目標要明確，最好有量化指標。
產品需求是否爲項目目標服務？有些項目，目標定的很好，但是需求列表，經不住推敲，與項目目標弱關聯甚至沒有關聯。乃至於很多需求都是基於假設，但這種假設卻經不起推敲。我們測試人員可以在項目前期，果斷的拒絕這類項目，或砍掉部分不現實的需求。減少項目後期的需求變更。這樣做，還可以減少上線後不必要的修復、縮減N次迭代，避免扯皮。
需求分析階段
需求一定要有優先級和重要程度。對於嘗試性的需求，在保障質量的同時，儘量減少投入工作量。對核心功能，優先保障自動化覆蓋。無論是在本次項目中，還是後續版本的迭代中需要不斷的進行重複測試，保障最核心功能的質量。測試人在需求分析階段儘可能細的拆分需求，通過場景法及各種異常分支流，驗證產品的功能是否完善，提前發現問題。
在這個階段，測試需要發揮自己的邏輯性思維優勢，幫助產品經理和開發們理清細節邏輯，讓產品更豐滿清晰，而不是乾癟癟走主流程。這樣會讓項目後期風險更可控，減少後期產品經理、開發、交互、測試之間的扯皮時間，減少需要變更次數。
不合理的需要要大膽的砍掉。試問有多少上線後就無人問津的生僻功能在前期白白浪費了大家的時間？這些產品的功能如果能在需求階段就砍掉，不知道可以節省多少人力成本。測試同學們可以更自信些，敢於向不合理的需求說NO。
設計階段
提高可測性設計，在設計階段，除關注產品的實現外，測試人員必須關注可測性設計。一個可測性設計好的產品，在測試執行過程中，可以大大減少測試執行時間，bug原因定位時間，測試驗證時間。
編碼階段
測試驅動開發
這裏的測試驅動開發不是嚴格意義上的。因爲在短平快的項目中，在一個未發展完全的團隊中，我們還不能在編寫某個功能代碼前，先編寫測試代碼。這裏的測試驅動開發是指利用測試的邏輯嚴密性，邏輯完善性，來指導開發編碼代碼。具體做法，測試人員第一時間產出業務邏輯導圖，並完成導圖評審。這裏指的評審是開發和測試、產品都在的外審。確保大家對需求的理解一致，產品功能的處理方式理解一致，這一點非常重要。之後，開發在編碼時，可以儘可能完善的考慮各種場景，異常流等。減少後期發現bug、提交bug、修復bug、再重複驗證bug等一系列返工。
代碼走讀
在開發編碼過程中，必要時進行代碼走讀，補充測試。這個過程，早期發現開發代碼級bug，又增加測試覆蓋度，從而減少測試過程中反覆，減少測試返工。
提測後
現在是測試人員發揮的時間了
大家會看到，在測試執行階段浪費的工時，被我們大大的拉到項目前期去了。還是那句話“測試儘量往前走，越早暴露問題越好”。