作者 | 于曉南

測試左移的由來

缺陷的修復(fù)成本逐步升高

下面是質(zhì)量領(lǐng)域司空見慣的一張圖，看圖說話，容易得出：大部分缺陷都是早期引入的，同時大部分缺陷都是中晚期發(fā)現(xiàn)的，而缺陷發(fā)現(xiàn)的越晚，其修復(fù)成本就越高。因此，為了降低缺陷修復(fù)成本，我們期望在更早的時間發(fā)現(xiàn)缺陷。

那么上圖是否完全沒問題呢？不是的，這張圖來源于1996年的一本書《Applied Software Measurement》，這張圖畫成的時候，敏捷宣言還沒誕生呢（敏捷宣言誕生于2001年）。在傳統(tǒng)背景下，需求是明確且相對固定的，需求產(chǎn)生的缺陷可以忽略不計。同時，在需求階段產(chǎn)生的問題可能會引起整體方案的返工，因此，需求產(chǎn)生的問題不太會以軟件缺陷的形式來體現(xiàn)。

需求質(zhì)量呼喚測試左移

隨著軟件生態(tài)的發(fā)展，軟件需求越來越復(fù)雜多變，需求的有效性和傳遞效率也備受挑戰(zhàn)。受大環(huán)境影響，需求階段引入的缺陷就對軟件的研發(fā)成本造成了影響。同時，軟件的研發(fā)過程越來越成為一個需要高效協(xié)作的整體，各角色之間的界限也變得相對模糊。

為了讓質(zhì)量理念更早的介入軟件研發(fā)過程，也為了降低缺陷修復(fù)的成本、減少不必要的返工，需求的質(zhì)量變得尤為重要。測試左移因此而生，需求分析人員與測試人員需要協(xié)同工作，共同保證需求的質(zhì)量。

加上需求階段重畫一下上面的圖，理想情況下，我們?nèi)菀椎贸鲆韵陆Y(jié)論：

• 缺陷的引入從需求階段就開始持續(xù)，到研發(fā)階段達到峰值，然后趨于平緩
• 缺陷從需求階段就開始陸續(xù)被發(fā)現(xiàn)，到測試階段達到峰值，然后趨于平緩
• 從需求階段到研發(fā)初期，缺陷修復(fù)的成本極低
• 開發(fā)后期到上線，缺陷修復(fù)成本一路攀升至高點
• 缺陷發(fā)現(xiàn)的數(shù)量少于引入的數(shù)量，但在上線前后，缺陷發(fā)現(xiàn)數(shù)量大于引入數(shù)量

因此，為了獲得更經(jīng)濟的資源投入產(chǎn)出比，我們認為應(yīng)該在需求階段和編碼初期更多的發(fā)現(xiàn)缺陷，從而減少修復(fù)成本和返工，這也正是測試左移的價值所在。

那么，該如何保證需求的質(zhì)量呢？我們在不同的時期面臨的需求，其形態(tài)是有差異的，所以需要深刻理解這些差異，并有針對性的設(shè)計質(zhì)量活動加以驗證。

需求的幾個層次

一個很現(xiàn)實的例子

一天，大老板說：“微信小程序不錯，我們內(nèi)部OA流程得做一個，你們安排一下，年內(nèi)發(fā)布就行。” 這就是一個來自大老板的一句話需求。

項目經(jīng)理拿到這個需求，看到“年內(nèi)發(fā)布”，需求管理看板上就可以多一張卡，只有幾個字“OA小程序”，排期可能暫時安排在第三季度。

過了倆月，送走了一批艱難的需求，暫時松口氣的項目經(jīng)理掃到這張卡，瞬間頭皮發(fā)麻，這還有一個老板親生的大坑呢，得盡快填上。喊來產(chǎn)品經(jīng)理，快出一版方案，再找技術(shù)經(jīng)理大致估一下工作量。

只有一句話顯然是沒法出方案的，產(chǎn)品經(jīng)理和技術(shù)經(jīng)理各自焦頭爛額的研究了兩天，又花了半天暫時碰出了OA小程序的初版方案。一周后，方案通過評審。這時，根據(jù)既定方案，產(chǎn)品經(jīng)理細化了一些需求：用戶管理，組織管理，流程管理，表單配置，權(quán)限配置，審批配置，微信登錄等。

即將進入研發(fā)階段，需求又會被再次細化。以用戶提交請假單的場景為例，需求可被細化如下圖。進入研發(fā)后，開發(fā)以一定的優(yōu)先級順序來領(lǐng)取需求進行研發(fā)。

需求的三種粒度

在上面的故事中，為了服務(wù)產(chǎn)品規(guī)劃和不同的管理訴求，需求呈現(xiàn)出以下三個粒度：

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

• 史詩故事 Epic：粗粒度的描述需求，通常需要多個迭代才能完成，主要用于版本規(guī)劃時記錄和跟蹤該功能
• 特性故事 Feature：也叫主題故事，是一系列相同主題用戶故事的集合，主要用于迭代規(guī)劃、優(yōu)先級排序和整體估算
• 用戶故事 Story：迭代開發(fā)的最小單元，是較細粒度的需求描述，主要用于迭代交付過程中的估算、跟蹤和管理

不同粒度需求的質(zhì)量保障

史詩故事：方案驗證 & 測試設(shè)計

在產(chǎn)品演進過程中，當面臨的需求還是一句話時，測試人員能做的事情并不多。當史詩故事即將進入迭代規(guī)劃，進行方案設(shè)計時，測試人員就可以參與進來了。

方案成型初期，測試人員可以參與方案討論和技術(shù)可行性研究，貢獻既有業(yè)務(wù)流程或潛在業(yè)務(wù)邏輯，針對有較大質(zhì)量風險的方案，測試人員有責任提出質(zhì)疑，并給出建議。

方案確定后，測試人員就可以著手進行測試設(shè)計了，測試設(shè)計包括但不限于：針對該功能的質(zhì)量預(yù)期，大致的測試規(guī)劃，現(xiàn)有的測試資源評估，主要的質(zhì)量風險及響應(yīng)方式等。

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

臨近迭代，需求會以特性的形式體現(xiàn)，此時測試人員可以參與需求評審：

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

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

用戶故事：需求驗收 & 測試執(zhí)行

故事啟動時，測試人員需要補充需求驗收的用例，以及需求影響范圍內(nèi)的回歸用例等。在這以后測試人員主要關(guān)注在需求驗收和測試執(zhí)行上，按照測試設(shè)計和計劃進行測試，確保最終的實現(xiàn)質(zhì)量。而在此階段，測試人員尤其需要關(guān)注投入產(chǎn)出比，把有限的精力用在刀刃上。行之有效的做法是在測試計劃階段就明確好各功能的質(zhì)量標準和資源投入，并在測試執(zhí)行階段時刻回顧。但計劃是死的，人是活的，萬一在測試過程中，我們發(fā)現(xiàn)計劃趕不上變化，就需要隨時跟團隊溝通并進行靈活調(diào)整了。

當然，質(zhì)量活動并不是以功能測完上線為結(jié)束，而是需要完成一個完整的閉環(huán)。測試階段以后的質(zhì)量活動不在本文討論的范圍內(nèi)，在此就不做過多展開了。

小結(jié)

測試左移之所以重要，是因為我們要在缺陷引入的最初階段就發(fā)現(xiàn)它，把缺陷扼殺在搖籃里，而不是等著它像雪球一樣越滾越大。而這里的誤區(qū)在于，測試左移要求的測試活動盡早介入，而不僅僅是把測試人員進行左移。因此，團隊里的每個成員，都需要有測試左移的思想，都可以從一開始就繃緊質(zhì)量這根弦，確保每個人的工件質(zhì)量。

而在需求的質(zhì)量保證活動中，測試人員也需要時不時換帽子，有時可能是終端用戶，有時可能是產(chǎn)品經(jīng)理，也有時可能是產(chǎn)品負責人。不管戴什么帽子，保證各個工件的質(zhì)量，以及各工件的順暢集成，都是測試人員可以關(guān)注的事。質(zhì)量相關(guān)，我們責無旁貸。?