敏捷項(xiàng)目下的傳統(tǒng)測試轉(zhuǎn)型之旅 | IDCF

來源：DevOps社區(qū)Meetup，本文曾發(fā)表于“《測試技術(shù)與質(zhì)量管理》季刊第19期”

作者：陳曉鵬。測試、敏捷及DevOps專家。德勤管理咨詢系統(tǒng)集成業(yè)務(wù)線測試負(fù)責(zé)人，中國商業(yè)聯(lián)合會互聯(lián)網(wǎng)委員會智庫專家，ISO29119軟件測試國際標(biāo)準(zhǔn)評審組專家。19年IT領(lǐng)域測試相關(guān)工作經(jīng)驗(yàn)，超過13年在IBM、埃森哲、德勤等國際頂尖IT咨詢及世界五百強(qiáng)公司工作。擅長測試咨詢與落地、項(xiàng)目管理、測試自動化及敏捷測試、DevOps等相關(guān)領(lǐng)域。

編輯：墨香

摘要：隨著這幾年業(yè)務(wù)的快速變化以及敏捷開發(fā)方法的流行，越來越多的組織都采用敏捷模式進(jìn)行項(xiàng)目開發(fā)。而這種時(shí)間極短且頻繁的迭代發(fā)布讓習(xí)慣于在傳統(tǒng)瀑布模式開發(fā)下的測試人員感到應(yīng)對吃力，心力交瘁。如果這樣的狀態(tài)持續(xù)下去，則對項(xiàng)目將是一個極大的風(fēng)險(xiǎn)。如何才能改變這種現(xiàn)狀，讓測試人員能更加順利的在敏捷項(xiàng)目下面進(jìn)行工作，既能保證進(jìn)度又能保證質(zhì)量呢？本文提出敏捷測試轉(zhuǎn)型模型，從文化、組織、流程、實(shí)踐等各個方面進(jìn)行闡述，為傳統(tǒng)測試轉(zhuǎn)型敏捷測試帶來指導(dǎo)意義。

一、傳統(tǒng)測試在敏捷環(huán)境下面臨的挑戰(zhàn)

敏捷開發(fā)模式和傳統(tǒng)瀑布開發(fā)模式有著不小的區(qū)別。對于測試人員而言，如果我們在敏捷項(xiàng)目中還是使用傳統(tǒng)瀑布開發(fā)模式的測試方法和實(shí)踐，將會碰到來自四個方面的挑戰(zhàn)：

• 時(shí)間極短

敏捷強(qiáng)調(diào)快速，一般一個迭代的周期為2-4周，在這么短的時(shí)間周期內(nèi)留給測試的時(shí)間寥寥無幾。測試人員如何做到既能完成測試任務(wù)同時(shí)還要保證質(zhì)量，將是一個巨大的挑戰(zhàn)。

• 文檔極少

敏捷的特點(diǎn)是輕文檔，意味著測試人員能看到的文檔信息內(nèi)容不會太詳細(xì)。因此在少文檔的情況下如何進(jìn)行測試用例設(shè)計(jì)以及判斷測試執(zhí)行是否通過，將是測試人員面臨的又一個棘手問題。

• 變更極頻

敏捷強(qiáng)調(diào)擁抱變化，所以在軟件開發(fā)過程中會存在不斷變更的可能。變更不但意味著在測試環(huán)境中可能存在多套測試版本，更有可能使得之前已經(jīng)做了一半的測試工作心血付諸東流。

• 資源極缺

敏捷提倡跨職能團(tuán)隊(duì)，所以淡化專職測試人員角色。在一個敏捷團(tuán)隊(duì)中，往往一個7-9人的團(tuán)隊(duì)只有1個功能測試人員。在測試人員極少的情況下如何能保障整個項(xiàng)目按時(shí)按質(zhì)完成，已經(jīng)成為令人頭痛的障礙。

二、敏捷環(huán)境下應(yīng)采用敏捷測試

既然在敏捷環(huán)境下不能再按照傳統(tǒng)的測試方式執(zhí)行，那么就需要有一套適合敏捷環(huán)境的新的測試實(shí)踐，我們稱之為敏捷測試。關(guān)于敏捷測試的定義，并沒有官方統(tǒng)一的標(biāo)準(zhǔn)。以下是維基百科對敏捷測試的定義：

“敏捷測試是遵從敏捷軟件開發(fā)原則的軟件測試實(shí)踐。敏捷測試包括跨功能敏捷團(tuán)隊(duì)的所有成員，以及測試人員提供的特殊專業(yè)知識，以確保可持續(xù)的速度頻繁地交付客戶所需的業(yè)務(wù)價(jià)值。”

從定義中我們都可以看出敏捷測試主要包含的核心內(nèi)涵有三點(diǎn)：

• 敏捷測試遵從敏捷開發(fā)的原則，強(qiáng)調(diào)遵守。所以敏捷價(jià)值觀和敏捷宣言遵循的12原則同樣適用在敏捷測試中。
• 測試被包含在整體開發(fā)流程中，強(qiáng)調(diào)融合。在敏捷開發(fā)過程中不再像傳統(tǒng)項(xiàng)目那樣有開發(fā)階段和測試階段之分，而是把開發(fā)和測試作為一個整體過程來看待。
• 跨職能團(tuán)隊(duì)，強(qiáng)調(diào)協(xié)作。跨職能意味著團(tuán)隊(duì)需要具備不同專業(yè)技能的人才共同組成，彼此之間互相協(xié)作、互相幫助，發(fā)揮每個人在團(tuán)隊(duì)中的優(yōu)勢，從而使得團(tuán)隊(duì)績效最大化。

三、往敏捷測試轉(zhuǎn)型的四個要素

在前面的討論中我們已經(jīng)知道傳統(tǒng)測試需要進(jìn)行轉(zhuǎn)型才能應(yīng)對這種快速迭代的工作模式。但是，接下來的問題是傳統(tǒng)測試到底需要在哪些領(lǐng)域做出改變呢？下面給出一個可以指導(dǎo)我們行動的敏捷測試轉(zhuǎn)型模型，如圖1所示。

圖1 敏捷測試轉(zhuǎn)型模型

讓我們來進(jìn)一步看看模型涉及到的四個要素：

3.1 文化

首先，文化轉(zhuǎn)變是敏捷轉(zhuǎn)型的基礎(chǔ)，脫離了文化，敏捷轉(zhuǎn)型就像無根之木、無源之水，最終可能將變成“偽敏捷”。所以文化轉(zhuǎn)變，具體到人的意識和思想觀的轉(zhuǎn)變，是整個敏捷測試轉(zhuǎn)型體系中最重要的要素。

3.2 組織

其次，在整個轉(zhuǎn)型過程離不開“組織”，組織結(jié)構(gòu)需要和未來的目標(biāo)相匹配才能確保轉(zhuǎn)型成功，所以轉(zhuǎn)型一定會涉及到組織這個要素，而且還會對敏捷測試轉(zhuǎn)型成功與否產(chǎn)生重大的影響，因此在模型中我們可以看到組織是在文化之上的又一個重要要素。

3.3 流程

再次，組織涉及到的是人，而人需要改變其做事的方式和過程，也就是工作流程。在敏捷框架下的流程和傳統(tǒng)測試的流程有非常大的不同，這就需要我們對測試角色和職責(zé)、測試流程等方面進(jìn)行重新調(diào)整，以達(dá)到適應(yīng)敏捷這種快速迭代的開發(fā)模式特點(diǎn)。

3.4 實(shí)踐

最后，我們知道敏捷有許多不同的實(shí)踐，這些實(shí)踐中很多都和測試有關(guān)，比如測試驅(qū)動開發(fā)TDD、行為驅(qū)動開發(fā)BDD、驗(yàn)收測試驅(qū)動開發(fā)ATDD等。因此我們在測試中可以借鑒和融合這些實(shí)踐，從而使我們能更加有信心的進(jìn)行敏捷測試轉(zhuǎn)型。

四、敏捷測試文化轉(zhuǎn)變

敏捷文化是敏捷測試轉(zhuǎn)型的基礎(chǔ)，只有具備敏捷文化的氛圍，對于組織架構(gòu)、流程和相關(guān)測試實(shí)踐的調(diào)整才有意義。在之前的敏捷測試定義中我們知道，敏捷測試是遵從敏捷軟件開發(fā)原則的一種測試實(shí)踐，因此敏捷的價(jià)值觀、敏捷宣言和敏捷12原則等同樣適用在敏捷測試中。除此之外，從傳統(tǒng)測試到敏捷測試的文化轉(zhuǎn)變還包括了組織文化轉(zhuǎn)變與管理文化轉(zhuǎn)變等。

4.1 組織文化轉(zhuǎn)變

• 小心變成質(zhì)量警察

在敏捷測試中，測試角色不再賦予測試人員決定是否可以上線的權(quán)利。項(xiàng)目的上線與否也不再是依賴某個人或者某個組，而是整個敏捷團(tuán)隊(duì)的決策。因此測試人員必須轉(zhuǎn)變思想，不要有“測試人員是項(xiàng)目上線的判官”心理，從實(shí)際出發(fā)，根據(jù)敏捷測試的要求來指導(dǎo)進(jìn)行測試。

• 可持續(xù)的速度而不是在項(xiàng)目尾段快速激烈的測試

在敏捷測試中是不認(rèn)可加班文化的。判斷團(tuán)隊(duì)能否加班的一條原則就是團(tuán)隊(duì)能否保持可持續(xù)的速度。如果只是偶爾加下班處理緊急的事情，不影響整體的交付速度，那無傷大雅；而如果是長期的加班使得測試人員處于一種疲勞、沮喪、情緒低落的狀態(tài)，那就說明開發(fā)過程不可持續(xù)，需要做改變。

• 合作伙伴式的客戶關(guān)系

在敏捷測試中，客戶與測試人員不再是甲乙方關(guān)系，而是合作伙伴的關(guān)系，大家有同一個目標(biāo)，那就是使項(xiàng)目成功。所以客戶會更頻繁的參與到項(xiàng)目的各個方面，而測試人員也需要更主動的與客戶進(jìn)行溝通，了解客戶需要什么、關(guān)注什么、擔(dān)心什么，從而能更好的幫助測試工作。

4.2 管理文化轉(zhuǎn)變

• 每個團(tuán)隊(duì)都有能力做出決定

每個團(tuán)隊(duì)都有能力做出決定，這個“能力”有兩層含義：一是外部相關(guān)。是指組織或者公司需要賦權(quán)給團(tuán)隊(duì)，讓團(tuán)隊(duì)有權(quán)利自己去決定相關(guān)的決策；二是內(nèi)部相關(guān)。是指團(tuán)隊(duì)內(nèi)部必須有能力去判斷和做出正確的決策。

• 提倡免責(zé)文化

無論在敏捷還是DevOps領(lǐng)域都是提倡免責(zé)文化，也就是不把犯錯誤跟績效考核掛鉤。原因在于敏捷是基于經(jīng)驗(yàn)性的，所以在敏捷的環(huán)境中，需要有不斷創(chuàng)新不斷嘗試的勇氣。而創(chuàng)新嘗試是有很高的失敗風(fēng)險(xiǎn)。在這種情況下如果還是把失敗與績效掛鉤，則會打擊嘗試者的積極性，久而久之大家寧愿墨守成規(guī)也不愿意嘗試創(chuàng)新，最終整個組織或者項(xiàng)目將會失去不斷自我改進(jìn)的活力。

• 管理層需要具備敏捷知識

有些管理層領(lǐng)導(dǎo)覺得敏捷是下面的人應(yīng)該去學(xué)習(xí)的，因?yàn)樗麄兪蔷唧w干活的，而管理層則沒必要學(xué)習(xí)敏捷知識。這其實(shí)是一個錯誤的想法。在Richard Knaster和Dean Leffingwell的著作《SAFe4.0精粹》一書中說到：企業(yè)的領(lǐng)導(dǎo)者必須擁抱精益-敏捷思維。如果領(lǐng)導(dǎo)者只是通過語言而不是他們自身的行動來支持敏捷，人們很快就會認(rèn)識到他不是全心全意在推動變革。他們必須知曉方法，強(qiáng)調(diào)終身學(xué)習(xí)，需要用新的行為踐行這些價(jià)值觀、原則和實(shí)踐。

五、敏捷測試組織轉(zhuǎn)變

傳統(tǒng)的項(xiàng)目組織是基于職能型組織架構(gòu)，團(tuán)隊(duì)成員來自不同的職能部門，比如需求部門、開發(fā)部門、測試部門等。這種組織架構(gòu)帶來的問題之一就是溝通模式成為“n”型模式，效率非常低。

而在敏捷環(huán)境中，組織架構(gòu)需要轉(zhuǎn)變成為跨職能團(tuán)隊(duì)，如圖2所示，也就是在團(tuán)隊(duì)里面會有不同技能的人員，可能包括業(yè)務(wù)分析、開發(fā)、測試，架構(gòu)師、甚至是DBA等角色。在這種模式下，團(tuán)隊(duì)的溝通會變得更加直接和有效，成員之間無需經(jīng)過間接的第三方進(jìn)行溝通傳達(dá)，而是經(jīng)常可以直接面對面進(jìn)行溝通，從而大大提高了溝通的效率。

圖2 敏捷測試組織架構(gòu)轉(zhuǎn)變

組織架構(gòu)調(diào)整后可能會出現(xiàn)測試人員的歸屬感問題。因?yàn)樵瓉淼臏y試部門沒有了，測試人員擔(dān)心他們的個人職業(yè)發(fā)展和技能培養(yǎng)由誰來關(guān)心？我們可以考慮成立測試實(shí)踐社區(qū)（Testing Communities of Practice）。

在SAFe中是如此定義實(shí)踐社區(qū)CoP的：

實(shí)踐社區(qū)是一個由團(tuán)隊(duì)成員和其他專家組成的非正式團(tuán)體，他們在一個項(xiàng)目群或企業(yè)環(huán)境中活動，并且擁有在一個或多個相關(guān)領(lǐng)域分享實(shí)踐知識的使命。

由定義可知，雖然CoP不是一個正式的團(tuán)體組織，無法承擔(dān)測試人員管理的職責(zé)，但是至少可以讓測試人員有一個“精神樂園”作為寄托，可以在里面學(xué)習(xí)與分享，減少測試人員的迷茫感。

六、敏捷測試流程轉(zhuǎn)變

6.1 敏捷測試類型

敏捷有不同層次的工件，而在這些不同的敏捷工件中，我們需要的測試范圍和測試策略也不一樣：

• 代碼：在Sprint層級中，我們需要對代碼進(jìn)行質(zhì)量掃描和單元測試，主要測試獨(dú)立的代碼單元是否正確。這個測試在單個Sprint內(nèi)完成，不會跨Sprint。
• 故事：在Sprint層級中，我們主要的測試對象是用戶故事。我們需要根據(jù)故事的驗(yàn)收標(biāo)準(zhǔn)進(jìn)行測試，這個測試是在Sprint迭代過程中執(zhí)行的，而且不會跨Sprint。
• 特性：在版本發(fā)布層級中，我們的測試對象是特性，主要是測試一些故事之間如何協(xié)同工作向用戶交付更大的價(jià)值。這個測試有些可以在Sprint內(nèi)完成，有些需要跨Sprint才能完成。
• 史詩：在版本發(fā)布層級中，我們測的對象是史詩，主要是跨多個特性的核心業(yè)務(wù)流程，通常是端到端的集成測試。這個測試通常都是要跨Sprint才能完成。

除此之外，對于非功能性的性能測試，無論是用戶故事、特性還是史詩，都需要考慮性能測試。在敏捷中，性能測試也需要提前并且分迭代來執(zhí)行，而不能只在最后階段再考慮。通過上面的介紹，我們知道了對于不同級別的敏捷工件使用不同的測試策略有助于將測試集中在交付的完整功能集上，從單元測試級別粒度一直到端到端業(yè)務(wù)流，如表1所示。

表1 敏捷測試中不同級別的測試類型

注：

• L1級別主要是針對單元組件模塊級別進(jìn)行的性能測試；
• L2級別主要是針對用戶故事級別進(jìn)行的性能測試；
• L3級別主要是針對整個版本端到端級別進(jìn)行的性能測試。

我們從上表中可以看到，有些測試類型是在Sprint迭代內(nèi)進(jìn)行的，而有些測試類型是需要跨Sprint來執(zhí)行的，因此我們可以簡單的把敏捷測試分成兩大類的測試類型：一類是Sprint內(nèi)測試（In-Sprint Testing）；另一類是跨Sprint測試（Cross-Sprint Testing），如下圖3所示。

圖3 Sprint中的敏捷測試類型

6.2 敏捷測試流程

敏捷測試的流程根據(jù)敏捷測試類型也分為兩類：一類是Sprint內(nèi)敏捷測試流程；一類是跨Sprint敏捷測試流程。敏捷測試流程如圖4所示，其中黑色區(qū)域部分主要是Sprint內(nèi)測試流程，而白色區(qū)域部分是跨Sprint測試流程。Sprint內(nèi)測試流程主要是針對每個用戶故事進(jìn)行的驗(yàn)證測試；跨Sprint測試主要是針對集成和回歸的版本測試。需要強(qiáng)調(diào)的是這里提供的敏捷測試流程只是作為參考的模板，并不是一成不變的。讀者可以根據(jù)自己組織和項(xiàng)目的特點(diǎn)對流程進(jìn)行剪裁，定制出適合自己項(xiàng)目環(huán)境的流程。

圖4 敏捷測試流程

跨Sprint敏捷測試流程一般應(yīng)用在版本發(fā)布級別，主要適用于多Scrum團(tuán)隊(duì)和多Sprint下環(huán)境下統(tǒng)一協(xié)作的情況。跨Sprint敏捷測試流程需要對不同Scrum團(tuán)隊(duì)和不同Sprint的交付物進(jìn)行集成和回歸驗(yàn)證測試，最終才能達(dá)到預(yù)發(fā)布的狀態(tài)。

在集成的過程，主要還是依靠CI/CD流程，同時(shí)輔助人工探索式測試來實(shí)現(xiàn)。CI/CD為多個Scrum團(tuán)隊(duì)的候選應(yīng)用版本部署到系統(tǒng)或發(fā)布集成環(huán)境中，同時(shí)會運(yùn)行回歸測試，驗(yàn)證這些應(yīng)用集成沒有問題并且通過人工的探索式測試后就能達(dá)到預(yù)發(fā)布的狀態(tài)。

七、敏捷測試實(shí)踐轉(zhuǎn)變

在討論完文化、組織和流程后，下面我們繼續(xù)討論最后一個實(shí)踐部分。首先我們可以按照開發(fā)過程中代碼推進(jìn)路徑的先后順序分成不同的環(huán)節(jié)：

• 需求到配置庫
• 代碼到開發(fā)環(huán)境
• 代碼到Sprint測試環(huán)境
• 代碼到集成/發(fā)布測試環(huán)境
• 代碼到生產(chǎn)環(huán)境

在這些環(huán)節(jié)中，代碼從一個環(huán)節(jié)傳到下一個環(huán)節(jié)，它的質(zhì)量應(yīng)該會好些；再傳到再下一個環(huán)節(jié)，它的質(zhì)量應(yīng)該又更好些......一直到生產(chǎn)環(huán)節(jié)，用戶最終可以接收到一個質(zhì)量可靠的產(chǎn)品。在這個過程中，這些環(huán)節(jié)就好像安置了一個“質(zhì)量漏斗”，代碼從一開始的輸入到最后的走向市場，經(jīng)過質(zhì)量漏斗的層層檢驗(yàn)后，質(zhì)量越來越好，直到最后代碼被部署到生產(chǎn)環(huán)境推向市場。在生產(chǎn)上線后，還需要監(jiān)控市場的接受度，收集并且確認(rèn)來自用戶的反饋，把反饋推給內(nèi)部的團(tuán)隊(duì)作為新的輸入，以此就建立了一個反饋環(huán)，如圖5所示。

圖5 敏捷測試實(shí)踐框架

在質(zhì)量漏斗中內(nèi)置了不同環(huán)節(jié)的質(zhì)量活動和賦能者來驅(qū)使質(zhì)量的不斷提升。這些質(zhì)量活動和賦能者不僅僅只在測試中才有，而是貫穿到整個開發(fā)過程中，這也是“質(zhì)量內(nèi)建”（Quality Build-in）的理念。

我們來看看不同的環(huán)節(jié)有什么樣的質(zhì)量活動和賦能者在其中：

• 需求到配置庫：這個環(huán)節(jié)是需求相關(guān)的環(huán)節(jié)，我們針對需求主要采用ATDD或者BDD的實(shí)踐進(jìn)行活動，同時(shí)也要考慮關(guān)于可用性的調(diào)研，可以通過低保真原型向最終用戶收集反饋。該環(huán)節(jié)的賦能者是BDD的框架、ATDD的框架，比如Cucumber、Specflow等。
• 代碼到開發(fā)環(huán)境：這個環(huán)節(jié)是單元測試環(huán)節(jié)，我們針對代碼主要進(jìn)行單元測試TDD、靜態(tài)代碼分析、代碼覆蓋率分析等活動。該環(huán)節(jié)的賦能者是XUnit框架、Jacoco代碼覆蓋率分析、SonarQube靜態(tài)代碼掃描等。
• 代碼到Sprint測試環(huán)境：這個環(huán)節(jié)是Sprint內(nèi)測試環(huán)節(jié)，我們針對代碼的功能性和非功能性進(jìn)行測試，主要的質(zhì)量活動包括功能測試、性能測試、安全測試等。該環(huán)節(jié)的賦能者是服務(wù)虛擬化、API和UI的測試自動化、組件和故事級別的性能測試等。
• 代碼到發(fā)布集成測試環(huán)境：這個環(huán)節(jié)主要是跨Sprint的UAT測試環(huán)節(jié)，主要包括端到端聯(lián)調(diào)測試、探索式測試、性能測試、可用性/易用性測試、安全測試等活動。該環(huán)節(jié)的賦能者是自動化測試框架、CI/CD流水線、安全漏洞掃描、用戶體驗(yàn)測試、系統(tǒng)級別的性能測試等。
• 代碼到生產(chǎn)環(huán)境：這個環(huán)節(jié)主要是上線后環(huán)節(jié)，包括的質(zhì)量活動如A/B測試、生產(chǎn)環(huán)境測試、混沌工程（Chaos Engineering）等。該環(huán)節(jié)的賦能者是自動化測試框架、生產(chǎn)監(jiān)控工具包括APM等。

最后我們再看不同環(huán)節(jié)的測試工作量分布。在代碼向后推進(jìn)的不同的環(huán)節(jié)中，我們的測試工作量是逐步減少的，這個也是和測試金字塔的理念一致的。

八、結(jié)語

讓我們再來回顧本文一開始提到的四個挑戰(zhàn)：

• 通過敏捷測試流程使得測試過程與敏捷迭代一致，解決了測試時(shí)間短的問題；
• 通過合作伙伴式的客戶關(guān)系文化轉(zhuǎn)變，使得我們不再需要描寫繁雜的需求文檔，我們通過與客戶頻繁溝通了解客戶的真正需要；
• 通過組織架構(gòu)向跨職能團(tuán)隊(duì)調(diào)整，質(zhì)量應(yīng)由團(tuán)隊(duì)保障，解決了專職測試資源少的問題；
• 通過敏捷測試實(shí)踐的自動化測試與持續(xù)集成，縮減反饋周期，使得在變更頻繁的情況下也能很好的保證質(zhì)量。
  

敏捷測試轉(zhuǎn)型不是一蹴而就的事情，需要組織持續(xù)不斷的堅(jiān)持才能成功。敏捷測試轉(zhuǎn)型過程中也沒有一套放之四海而皆準(zhǔn)的標(biāo)準(zhǔn)，所以轉(zhuǎn)型者也需要按照敏捷的方式小步進(jìn)行、回顧評審、重新調(diào)整、再小步進(jìn)行……相信通過這樣的方式成功一定會在不遠(yuǎn)之處等著我們。

參考文獻(xiàn)

• [1] SAFe4.0精粹 電子工業(yè)出版社 (美)理查德·克納斯特,(美)迪恩·萊芬韋爾著
• [2] Scrum精髓 清華大學(xué)出版社 （美）凱恩魯本著
• [3] 維基百科

本文作者敏捷測試專家陳曉鵬老師的課程【IDCF訓(xùn)練營-敏捷測試方法與實(shí)踐訓(xùn)練營】，6個專題，450分鐘，詳細(xì)討論傳統(tǒng)測試如何敏捷轉(zhuǎn)型，帶給您最新的敏捷測試知識。限時(shí)團(tuán)購優(yōu)惠，識別下圖二維碼即可拼團(tuán)學(xué)習(xí)，趕快加入吧~