測試左移：需求相關的質量保障 | IDCF

1、測試左移的由來

1.1 缺陷的修復成本逐步升高

下面是質量領域司空見慣的一張圖，看圖說話，容易得出：大部分缺陷都是早期引入的，同時大部分缺陷都是中晚期發現的，而缺陷發現得越晚，其修復成本就越高。

所以，爲了下降缺陷修復成本，咱們指望在更早的時間發現缺陷。

那麼上圖是否徹底沒問題呢？不是的，這張圖來源於1996年的一本書《Applied Software Measurement》，這張圖畫成的時候，敏捷宣言還沒誕生呢（敏捷宣言誕生於2001年）。在傳統背景下，需求是明確且相對固定的，需求產生的缺陷能夠忽略不計。同時，在需求階段產生的問題可能會引發總體方案的返工，所以，需求產生的問題不太會以軟件缺陷的形式來體現。

1.2 需求質量呼喚測試左移

隨着軟件生態的發展，軟件需求愈來愈複雜多變，需求的有效性和傳遞效率也備受挑戰。受大環境影響，需求階段引入的缺陷就對軟件的研發成本形成了影響。同時，軟件的研發過程愈來愈成爲一個須要高效協做的總體，各角色之間的界限也變得相對模糊。

爲了讓質量理念更早的介入軟件研發過程，也爲了下降缺陷修復的成本、減小沒必要要的返工，需求的質量變得尤其重要。測試左移所以而生，需求分析人員與測試人員須要協同工做，共同保證需求的質量。

加上需求階段重畫一下上面的圖，理想狀況下，咱們容易得出如下結論：

• 缺陷的引入從需求階段就開始持續，到研發階段達到峯值，而後趨於平緩；
• 缺陷從需求階段就開始陸續被發現，到測試階段達到峯值，而後趨於平緩；
• 從需求階段到研發初期，缺陷修復的成本極低；
• 開發後期到上線，缺陷修復成本一路攀升至高點；
• 缺陷發現的數量少於引入的數量，但在上線先後，缺陷發現數量大於引入數量。

所以，爲了得到更經濟的資源投入產出比，咱們認爲應該在需求階段和編碼初期更多地發現缺陷，從而減小修覆成本和返工，這也正是測試左移的價值所在。

那麼，該如何保證需求的質量呢？咱們在不一樣的時期面臨的需求，其形態是有差別的，因此須要深入理解這些差別，並有針對性地設計質量活動加以驗證。

2、需求的三個層次

2.1 一個很現實的例子

一天，大老闆說：「微信小程序不錯，咱們內部OA流程得作一個，大家安排一下，年內發佈就行。」 這就是一個來自大老闆的一句話需求。

項目經理拿到這個需求，看到「年內發佈」，需求管理看板上就能夠多一張卡，只有幾個字「OA小程序」，排期可能暫時安排在第三季度。

過了倆月，送走了一批艱難的需求，暫時鬆口氣的項目經理掃到這張卡，瞬間頭皮發麻，這還有一個老闆親生的大坑呢，得儘快填上。喊來產品經理，快出一版方案，再找技術經理大體估一下工做量。

只有一句話顯然是無法出方案的，產品經理和技術經理各自焦頭爛額的研究了兩天，又花了半天暫時碰出了OA小程序的第一版方案。一週後，方案經過評審。這時，根據既定方案，產品經理細化了一些需求：用戶管理，組織管理，流程管理，表單配置，權限配置，審批配置，微信登陸等。

即將進入研發階段，需求又會被再次細化。以用戶提交請假單的場景爲例，需求可被細化以下圖。進入研發後，開發以必定的優先級順序來領取需求進行研發。

2.2 需求的三種粒度

在上面的故事中，爲了服務產品規劃和不一樣的管理訴求，需求呈現出如下三個粒度：

史詩故事 > 特性故事 > 用戶故事

• 史詩故事 Epic：粗粒度的描述需求，一般須要多個迭代才能完成，主要用於版本規劃時記錄和跟蹤該功能；
• 特性故事 Feature：也叫主題故事，是一系列相同主題用戶故事的集合，主要用於迭代規劃、優先級排序和總體估算；
• 用戶故事 Story：迭代開發的最小單元，是細粒度的需求描述，主要用於迭代交付過程當中的估算、跟蹤和管理。

3、不一樣粒度的需求保障

3.1 史詩故事：方案驗證 & 測試設計

在產品演進過程當中，當面臨的需求仍是一句話時，測試人員能作的事情並很少。當史詩故事即將進入迭代規劃，進行方案設計時，測試人員就能夠參與進來了。

方案成型初期，測試人員能夠參與方案討論和技術可行性研究，貢獻既有業務流程或潛在業務邏輯，針對有較大質量風險的方案，測試人員有責任提出質疑，並給出建議。

方案肯定後，測試人員就能夠着手進行測試設計了，測試設計包括但不限於：針對該功能的質量預期，大體的測試規劃，現有的測試資源評估，主要的質量風險及響應方式等。

3.2 特性故事：需求評審 & 測試計劃

臨近迭代，需求會以特性的形式體現，此時測試人員能夠參與需求評審：

• 針對功能需求，測試人員先驗證需求是否有效，包括需求價值確認，需求涉及場景是否完備，與現有業務邏輯是否有衝突；
• 針對功能需求背後的支撐性需求進行澄清，確認支撐性需求的範圍、驗收標準、測試方式等；此外還須要考慮用戶體驗；
• 考慮需求的拆分是否合理，是否便於估算和迭代管理。

質量活動方面，測試人員能夠落實測試計劃了，如各類測試活動的安排，測試效果的評價，測試的重點和難點，測試階段的輸入和輸出等，在這個階段均可以確認了。

3.3 用戶故事：需求驗收 & 測試執行

故事啓動時，測試人員須要補充需求驗收的用例，以及需求影響範圍內的迴歸用例等。在這之後測試人員主要關注在需求驗收和測試執行上，按照測試設計和計劃進行測試，確保最終的實現質量。而在此階段，測試人員尤爲須要關注投入產出比，把有限的精力用在刀刃上。行之有效的作法是在測試計劃階段就明確好各功能的質量標準和資源投入，並在測試執行階段時刻回顧。但計劃是死的，人是活的，萬一在測試過程當中，咱們發現計劃趕不上變化，就須要隨時跟團隊溝通並進行靈活調整了。

固然，質量活動並非以功能測完上線爲結束，而是須要完成一個完整的閉環。測試階段之後的質量活動不在本文討論的範圍內，在此就不作過多展開了。

4、小結

測試左移之因此重要，是由於咱們要在缺陷引入的最初階段就發現它，把缺陷扼殺在搖籃裏，而不是等着它像雪球同樣越滾越大。而這裏的誤區在於，測試左移要求的是測試活動儘早介入，而不只僅是把測試人員進行左移。所以，團隊裏的每一個成員，都須要有測試左移的思想，均可以從一開始就繃緊質量這根弦，確保每一個人的工件質量。

而在需求的質量保證活動中，測試人員也須要時不時換帽子，有時多是終端用戶，有時多是產品經理，也有時多是產品負責人。無論戴什麼帽子，保證各個工件的質量，以及各工件的順暢集成，都是測試人員能夠關注的事。質量相關，咱們義不容辭。

來源：圓小豆的好夢工場
做者：於曉南
聲明：文章得到做者受權在IDCF社區公衆號（devopshub）轉發。優質內容共享給思否平臺的技術同伴，如原做者有其餘考慮請聯繫小編刪除，致謝。

5月每週四晚8點，【冬哥有話說】質量與測試專場。公衆號留言「質量」可獲取地址

• 0506 朱少民 《如何最大化軟件測試效能》
• 0513 陳琦 《數據驅動測試》
• 0520 陳霽 《沒錯，去QA是提升質量最有效的方法！》
• 0527 施慧斌 《DevOps實踐之持續測試》