測試左移的由來
缺陷的修復成本逐步升高
下面是質量領域司空見慣的一張圖，看圖說話，容易得出：大部分缺陷都是早期引入的，同時大部分缺陷都是中晚期發現的，而缺陷發現的越晚，其修復成本就越高。因此，爲了降低缺陷修復成本，我們期望在更早的時間發現缺陷。
那麼上圖是否完全沒問題呢？不是的，這張圖來源於1996年的一本書《Applied Software Measurement》，這張圖畫成的時候，敏捷宣言還沒誕生呢（敏捷宣言誕生於2001年）。在傳統背景下，需求是明確且相對固定的，需求產生的缺陷可以忽略不計。同時，在需求階段產生的問題可能會引起整體方案的返工，因此，需求產生的問題不太會以軟件缺陷的形式來體現。
需求質量呼喚測試左移
隨着軟件生態的發展，軟件需求越來越複雜多變，需求的有效性和傳遞效率也備受挑戰。受大環境影響，需求階段引入的缺陷就對軟件的研發成本造成了影響。同時，軟件的研發過程越來越成爲一個需要高效協作的整體，各角色之間的界限也變得相對模糊。
爲了讓質量理念更早的介入軟件研發過程，也爲了降低缺陷修復的成本、減少不必要的返工，需求的質量變得尤爲重要。測試左移因此而生，需求分析人員與測試人員需要協同工作，共同保證需求的質量。
加上需求階段重畫一下上面的圖，理想情況下，我們容易得出以下結論：
- 缺陷的引入從需求階段就開始持續，到研發階段達到峯值，然後趨於平緩
- 缺陷從需求階段就開始陸續被發現，到測試階段達到峯值，然後趨於平緩
- 從需求階段到研發初期，缺陷修復的成本極低
- 開發後期到上線，缺陷修復成本一路攀升至高點
- 缺陷發現的數量少於引入的數量，但在上線前後，缺陷發現數量大於引入數量
因此，爲了獲得更經濟的資源投入產出比，我們認爲應該在需求階段和編碼初期更多的發現缺陷，從而減少修復成本和返工，這也正是測試左移的價值所在。
那麼，該如何保證需求的質量呢？我們在不同的時期面臨的需求，其形態是有差異的，所以需要深刻理解這些差異，並有針對性的設計質量活動加以驗證。
需求的幾個層次
一個很現實的例子
一天，大老闆說：“微信小程序不錯，我們內部OA流程得做一個，你們安排一下，年內發佈就行。” 這就是一個來自大老闆的一句話需求。
項目經理拿到這個需求，看到“年內發佈”，需求管理看板上就可以多一張卡，只有幾個字“OA小程序”，排期可能暫時安排在第三季度。
過了倆月，送走了一批艱難的需求，暫時鬆口氣的項目經理掃到這張卡，瞬間頭皮發麻，這還有一個老闆親生的大坑呢，得儘快填上。喊來產品經理，快出一版方案，再找技術經理大致估一下工作量。
只有一句話顯然是沒法出方案的，產品經理和技術經理各自焦頭爛額的研究了兩天，又花了半天暫時碰出了OA小程序的初版方案。一週後，方案通過評審。這時，根據既定方案，產品經理細化了一些需求：用戶管理，組織管理，流程管理，表單配置，權限配置，審批配置，微信登錄等。
即將進入研發階段，需求又會被再次細化。以用戶提交請假單的場景爲例，需求可被細化如下圖。進入研發後，開發以一定的優先級順序來領取需求進行研發。
需求的三種粒度
在上面的故事中，爲了服務產品規劃和不同的管理訴求，需求呈現出以下三個粒度：
史詩故事 > 特性故事 > 用戶故事
- 史詩故事 Epic：粗粒度的描述需求，通常需要多個迭代才能完成，主要用於版本規劃時記錄和跟蹤該功能
- 特性故事 Feature：也叫主題故事，是一系列相同主題用戶故事的集合，主要用於迭代規劃、優先級排序和整體估算
- 用戶故事 Story：迭代開發的最小單元，是較細粒度的需求描述，主要用於迭代交付過程中的估算、跟蹤和管理
不同粒度需求的質量保障
史詩故事：方案驗證 & 測試設計
在產品演進過程中，當面臨的需求還是一句話時，測試人員能做的事情並不多。當史詩故事即將進入迭代規劃，進行方案設計時，測試人員就可以參與進來了。
方案成型初期，測試人員可以參與方案討論和技術可行性研究，貢獻既有業務流程或潛在業務邏輯，針對有較大質量風險的方案，測試人員有責任提出質疑，並給出建議。
方案確定後，測試人員就可以着手進行測試設計了，測試設計包括但不限於：針對該功能的質量預期，大致的測試規劃，現有的測試資源評估，主要的質量風險及響應方式等。
特性故事：需求評審 & 測試計劃
臨近迭代，需求會以特性的形式體現，此時測試人員可以參與需求評審：
- 針對功能需求，測試人員先驗證需求是否有效，包括需求價值確認，需求涉及場景是否完備，與現有業務邏輯是否有衝突
- 針對功能需求背後的支撐性需求進行澄清，確認支撐性需求的範圍、驗收標準、測試方式等；此外還需要考慮用戶體驗
- 考慮需求的拆分是否合理，是否便於估算和迭代管理
質量活動方面，測試人員可以落實測試計劃了，如各種測試活動的安排，測試效果的評價，測試的重點和難點，測試階段的輸入和輸出等，在這個階段都可以確認了。
用戶故事：需求驗收 & 測試執行
故事啓動時，測試人員需要補充需求驗收的用例，以及需求影響範圍內的迴歸用例等。在這以後測試人員主要關注在需求驗收和測試執行上，按照測試設計和計劃進行測試，確保最終的實現質量。而在此階段，測試人員尤其需要關注投入產出比，把有限的精力用在刀刃上。行之有效的做法是在測試計劃階段就明確好各功能的質量標準和資源投入，並在測試執行階段時刻回顧。但計劃是死的，人是活的，萬一在測試過程中，我們發現計劃趕不上變化，就需要隨時跟團隊溝通並進行靈活調整了。
當然，質量活動並不是以功能測完上線爲結束，而是需要完成一個完整的閉環。測試階段以後的質量活動不在本文討論的範圍內，在此就不做過多展開了。
小結
測試左移之所以重要，是因爲我們要在缺陷引入的最初階段就發現它，把缺陷扼殺在搖籃裏，而不是等着它像雪球一樣越滾越大。而這裏的誤區在於，測試左移要求的測試活動儘早介入，而不僅僅是把測試人員進行左移。因此，團隊裏的每個成員，都需要有測試左移的思想，都可以從一開始就繃緊質量這根弦，確保每個人的工件質量。
而在需求的質量保證活動中，測試人員也需要時不時換帽子，有時可能是終端用戶，有時可能是產品經理，也有時可能是產品負責人。不管戴什麼帽子，保證各個工件的質量，以及各工件的順暢集成，都是測試人員可以關注的事。質量相關，我們責無旁貸。
文/Thoughtworks 於曉南
原文鏈接：https://insights.thoughtworks.cn/shift-left-testing/