測(cè)試左移的由來(lái)

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

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

缺陷的發(fā)現(xiàn)和修復(fù)成本

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

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

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

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

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

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

缺陷發(fā)現(xiàn)-修復(fù)成本（添加需求階段）

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

那么，該如何保證需求的質(zhì)量呢？我們?cè)诓煌臅r(shí)期面臨的需求，其形態(tài)是有差異的，所以需要深刻理解這些差異，并有針對(duì)性的設(shè)計(jì)質(zhì)量活動(dòng)加以驗(yàn)證。

需求的三個(gè)層次

一個(gè)很現(xiàn)實(shí)的例子

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

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

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

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

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

迭代過(guò)程中的不同需求粒度

需求的三種粒度

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

史詩(shī)故事 > 特性故事 > 用戶故事

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

史詩(shī)故事、特性故事、用戶故事與迭代的關(guān)系

不同粒度的需求保障

史詩(shī)故事：方案驗(yàn)證 & 測(cè)試設(shè)計(jì)

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

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

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

問(wèn)題是正確的問(wèn)題嗎？方案是正確的方案嗎？

特性故事：需求評(píng)審 & 測(cè)試計(jì)劃

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

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

質(zhì)量活動(dòng)方面，測(cè)試人員可以落實(shí)測(cè)試計(jì)劃了，如各種測(cè)試活動(dòng)的安排，測(cè)試效果的評(píng)價(jià)，測(cè)試的重點(diǎn)和難點(diǎn)，測(cè)試階段的輸入和輸出等，在這個(gè)階段都可以確認(rèn)了。

用戶故事：需求驗(yàn)收 & 測(cè)試執(zhí)行

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

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

如何驗(yàn)證需求的質(zhì)量

小結(jié)

測(cè)試左移之所以重要，是因?yàn)槲覀円谌毕菀氲淖畛蹼A段就發(fā)現(xiàn)它，把缺陷扼殺在搖籃里，而不是等著它像雪球一樣越滾越大。而這里的誤區(qū)在于，測(cè)試左移要求的是測(cè)試活動(dòng)盡早介入，而不僅僅是把測(cè)試人員進(jìn)行左移。因此，團(tuán)隊(duì)里的每個(gè)成員，都需要有測(cè)試左移的思想，都可以從一開(kāi)始就繃緊質(zhì)量這根弦，確保每個(gè)人的工件質(zhì)量。

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