在快速迭代的項目中減小測試返工

概述

　　在互聯網產品中，產品的迭代速度愈來愈快，項目中的測試同窗面臨着前期需求搖擺不定，中間各類開發進度死鎖，而發佈時間卻沒法推遲。項目的前期階段彷佛老是在壓榨着測試的執行時間。

　　如何減小測試返工，測試階段的工做量的同時，保障項目質量？

　　立項後

　　項目目標要明確，最好有量化指標。

　　產品需求是否爲項目目標服務？有些項目，目標定的很好，可是需求列表，經不住推敲，與項目目標弱關聯甚至沒有關聯。乃至於不少需求都是基於假設，但這種假設卻經不起推敲。咱們測試人員能夠在項目前期，果斷的拒絕這類項目，或砍掉部分不現實的需求。減小項目後期的需求變動。這樣作，還能夠減小上線後沒必要要的修復、縮減N次迭代，避免扯皮。

　　需求分析階段

　　需求必定要有優先級和重要程度。對於嘗試性的需求，在保障質量的同時，儘可能減小投入工做量。對核心功能，優先保障自動化覆蓋。不管是在本次項目中，仍是後續版本的迭代中須要不斷的進行重複測試，保障最核心功能的質量。測試人在需求分析階段儘量細的拆分需求，經過場景法及各類異常分支流，驗證產品的功能是否完善，提早發現問題。

　　在這個階段，測試須要發揮本身的邏輯性思惟優點，幫助產品經理和開發們理清細節邏輯，讓產品更豐滿清晰，而不是乾癟癟走主流程。這樣會讓項目後期風險更可控，減小後期產品經理、開發、交互、測試之間的扯皮時間，減小須要變動次數。

　　不合理的須要要大膽的砍掉。試問有多少上線後就無人問津的生僻功能在前期白白浪費了你們的時間？這些產品的功能若是能在需求階段就砍掉，不知道能夠節省多少人力成本。測試同窗們能夠更自信些，勇於向不合理的需求說NO。

　　設計階段  

　　提升可測性設計，在設計階段，除關注產品的實現外，測試人員必須關注可測性設計。一個可測性設計好的產品，在測試執行過程當中，能夠大大減小測試執行時間，bug緣由定位時間，測試驗證時間。

　    編碼階段

　　測試驅動開發    

　　這裏的測試驅動開發不是嚴格意義上的。由於在短平快的項目中，在一個未發展徹底的團隊中，咱們還不能在編寫某個功能代碼前，先編寫測試代碼。這裏的測試驅動開發是指利用測試的邏輯嚴密性，邏輯完善性，來指導開發編碼代碼。具體作法，測試人員第一時間產出業務邏輯導圖，並完成導圖評審。這裏指的評審是開發和測試、產品都在的外審。確保你們對需求的理解一致，產品功能的處理方式理解一致，這一點很是重要。以後，開發在編碼時，能夠儘量完善的考慮各類場景，異常流等。減小後期發現bug、提交bug、修復bug、再重複驗證bug等一系列返工。

　代碼走讀

　　在開發編碼過程當中，必要時進行代碼走讀，補充測試。這個過程，早期發現開發代碼級bug，又增長測試覆蓋度，從而減小測試過程當中反覆，減小測試返工。

　　提測後 

　如今是測試人員發揮的時間了

　你們會看到，在測試執行階段浪費的工時，被咱們大大的拉到項目前期去了。仍是那句話「測試儘可能往前走，越早暴露問題越好」。

 

點擊加入QQ羣，和咱們一塊兒學習