敏捷專案下的傳統測試轉型之旅 | IDCF

來源：DevOps社群Meetup，本文曾發表於“《測試技術與質量管理》季刊第19期”

作者：陳曉鵬。測試、敏捷及DevOps專家。德勤管理諮詢系統整合業務線測試負責人，中國商業聯合會網際網路委員會智庫專家，ISO29119軟體測試國際標準評審組專家。19年IT領域測試相關工作經驗，超過13年在IBM、埃森哲、德勤等國際頂尖IT諮詢及世界五百強公司工作。擅長測試諮詢與落地、專案管理、測試自動化及敏捷測試、DevOps等相關領域。

編輯：墨香

摘要：隨著這幾年業務的快速變化以及敏捷開發方法的流行，越來越多的組織都採用敏捷模式進行專案開發。而這種時間極短且頻繁的迭代釋出讓習慣於在傳統瀑布模式開發下的測試人員感到應對吃力，心力交瘁。如果這樣的狀態持續下去，則對專案將是一個極大的風險。如何才能改變這種現狀，讓測試人員能更加順利的在敏捷專案下面進行工作，既能保證進度又能保證質量呢？本文提出敏捷測試轉型模型，從文化、組織、流程、實踐等各個方面進行闡述，為傳統測試轉型敏捷測試帶來指導意義。

一、傳統測試在敏捷環境下面臨的挑戰

敏捷開發模式和傳統瀑布開發模式有著不小的區別。對於測試人員而言，如果我們在敏捷專案中還是使用傳統瀑布開發模式的測試方法和實踐，將會碰到來自四個方面的挑戰：

• 時間極短

敏捷強調快速，一般一個迭代的週期為2-4周，在這麼短的時間週期內留給測試的時間寥寥無幾。測試人員如何做到既能完成測試任務同時還要保證質量，將是一個巨大的挑戰。

• 文件極少

敏捷的特點是輕文件，意味著測試人員能看到的文件資訊內容不會太詳細。因此在少文件的情況下如何進行測試用例設計以及判斷測試執行是否透過，將是測試人員面臨的又一個棘手問題。

• 變更極頻

敏捷強調擁抱變化，所以在軟體開發過程中會存在不斷變更的可能。變更不但意味著在測試環境中可能存在多套測試版本，更有可能使得之前已經做了一半的測試工作心血付諸東流。

• 資源極缺

敏捷提倡跨職能團隊，所以淡化專職測試人員角色。在一個敏捷團隊中，往往一個7-9人的團隊只有1個功能測試人員。在測試人員極少的情況下如何能保障整個專案按時按質完成，已經成為令人頭痛的障礙。

二、敏捷環境下應採用敏捷測試

既然在敏捷環境下不能再按照傳統的測試方式執行，那麼就需要有一套適合敏捷環境的新的測試實踐，我們稱之為敏捷測試。關於敏捷測試的定義，並沒有官方統一的標準。以下是維基百科對敏捷測試的定義：

“敏捷測試是遵從敏捷軟體開發原則的軟體測試實踐。敏捷測試包括跨功能敏捷團隊的所有成員，以及測試人員提供的特殊專業知識，以確保可持續的速度頻繁地交付客戶所需的業務價值。”

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

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

三、往敏捷測試轉型的四個要素

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

圖1 敏捷測試轉型模型

讓我們來進一步看看模型涉及到的四個要素：

3.1 文化

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

3.2 組織

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

3.3 流程

再次，組織涉及到的是人，而人需要改變其做事的方式和過程，也就是工作流程。在敏捷框架下的流程和傳統測試的流程有非常大的不同，這就需要我們對測試角色和職責、測試流程等方面進行重新調整，以達到適應敏捷這種快速迭代的開發模式特點。

3.4 實踐

最後，我們知道敏捷有許多不同的實踐，這些實踐中很多都和測試有關，比如測試驅動開發TDD、行為驅動開發BDD、驗收測試驅動開發ATDD等。因此我們在測試中可以借鑑和融合這些實踐，從而使我們能更加有信心的進行敏捷測試轉型。

四、敏捷測試文化轉變

敏捷文化是敏捷測試轉型的基礎，只有具備敏捷文化的氛圍，對於組織架構、流程和相關測試實踐的調整才有意義。在之前的敏捷測試定義中我們知道，敏捷測試是遵從敏捷軟體開發原則的一種測試實踐，因此敏捷的價值觀、敏捷宣言和敏捷12原則等同樣適用在敏捷測試中。除此之外，從傳統測試到敏捷測試的文化轉變還包括了組織文化轉變與管理文化轉變等。

4.1 組織文化轉變

• 小心變成質量警察

在敏捷測試中，測試角色不再賦予測試人員決定是否可以上線的權利。專案的上線與否也不再是依賴某個人或者某個組，而是整個敏捷團隊的決策。因此測試人員必須轉變思想，不要有“測試人員是專案上線的判官”心理，從實際出發，根據敏捷測試的要求來指導進行測試。

• 可持續的速度而不是在專案尾段快速激烈的測試

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

• 合作伙伴式的客戶關係

在敏捷測試中，客戶與測試人員不再是甲乙方關係，而是合作伙伴的關係，大家有同一個目標，那就是使專案成功。所以客戶會更頻繁的參與到專案的各個方面，而測試人員也需要更主動的與客戶進行溝通，瞭解客戶需要什麼、關注什麼、擔心什麼，從而能更好的幫助測試工作。

4.2 管理文化轉變

• 每個團隊都有能力做出決定

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

• 提倡免責文化

無論在敏捷還是DevOps領域都是提倡免責文化，也就是不把犯錯誤跟績效考核掛鉤。原因在於敏捷是基於經驗性的，所以在敏捷的環境中，需要有不斷創新不斷嘗試的勇氣。而創新嘗試是有很高的失敗風險。在這種情況下如果還是把失敗與績效掛鉤，則會打擊嘗試者的積極性，久而久之大家寧願墨守成規也不願意嘗試創新，最終整個組織或者專案將會失去不斷自我改進的活力。

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

有些管理層領導覺得敏捷是下面的人應該去學習的，因為他們是具體幹活的，而管理層則沒必要學習敏捷知識。這其實是一個錯誤的想法。在Richard Knaster和Dean Leffingwell的著作《SAFe4.0精粹》一書中說到：企業的領導者必須擁抱精益-敏捷思維。如果領導者只是透過語言而不是他們自身的行動來支援敏捷，人們很快就會認識到他不是全心全意在推動變革。他們必須知曉方法，強調終身學習，需要用新的行為踐行這些價值觀、原則和實踐。

五、敏捷測試組織轉變

傳統的專案組織是基於職能型組織架構，團隊成員來自不同的職能部門，比如需求部門、開發部門、測試部門等。這種組織架構帶來的問題之一就是溝通模式成為“n”型模式，效率非常低。

而在敏捷環境中，組織架構需要轉變成為跨職能團隊，如圖2所示，也就是在團隊裡面會有不同技能的人員，可能包括業務分析、開發、測試，架構師、甚至是DBA等角色。在這種模式下，團隊的溝通會變得更加直接和有效，成員之間無需經過間接的第三方進行溝通傳達，而是經常可以直接面對面進行溝通，從而大大提高了溝通的效率。

圖2 敏捷測試組織架構轉變

組織架構調整後可能會出現測試人員的歸屬感問題。因為原來的測試部門沒有了，測試人員擔心他們的個人職業發展和技能培養由誰來關心？我們可以考慮成立測試實踐社群（Testing Communities of Practice）。

在SAFe中是如此定義實踐社群CoP的：

實踐社群是一個由團隊成員和其他專家組成的非正式團體，他們在一個專案群或企業環境中活動，並且擁有在一個或多個相關領域分享實踐知識的使命。

由定義可知，雖然CoP不是一個正式的團體組織，無法承擔測試人員管理的職責，但是至少可以讓測試人員有一個“精神樂園”作為寄託，可以在裡面學習與分享，減少測試人員的迷茫感。

六、敏捷測試流程轉變

6.1 敏捷測試型別

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

• 程式碼：在Sprint層級中，我們需要對程式碼進行質量掃描和單元測試，主要測試獨立的程式碼單元是否正確。這個測試在單個Sprint內完成，不會跨Sprint。
• 故事：在Sprint層級中，我們主要的測試物件是使用者故事。我們需要根據故事的驗收標準進行測試，這個測試是在Sprint迭代過程中執行的，而且不會跨Sprint。
• 特性：在版本釋出層級中，我們的測試物件是特性，主要是測試一些故事之間如何協同工作向使用者交付更大的價值。這個測試有些可以在Sprint內完成，有些需要跨Sprint才能完成。
• 史詩：在版本釋出層級中，我們測的物件是史詩，主要是跨多個特性的核心業務流程，通常是端到端的整合測試。這個測試通常都是要跨Sprint才能完成。

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

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

注：

• L1級別主要是針對單元元件模組級別進行的效能測試；
• L2級別主要是針對使用者故事級別進行的效能測試；
• L3級別主要是針對整個版本端到端級別進行的效能測試。

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

圖3 Sprint中的敏捷測試型別

6.2 敏捷測試流程

敏捷測試的流程根據敏捷測試型別也分為兩類：一類是Sprint內敏捷測試流程；一類是跨Sprint敏捷測試流程。敏捷測試流程如圖4所示，其中黑色區域部分主要是Sprint內測試流程，而白色區域部分是跨Sprint測試流程。Sprint內測試流程主要是針對每個使用者故事進行的驗證測試；跨Sprint測試主要是針對整合和迴歸的版本測試。需要強調的是這裡提供的敏捷測試流程只是作為參考的模板，並不是一成不變的。讀者可以根據自己組織和專案的特點對流程進行剪裁，定製出適合自己專案環境的流程。

圖4 敏捷測試流程

跨Sprint敏捷測試流程一般應用在版本釋出級別，主要適用於多Scrum團隊和多Sprint下環境下統一協作的情況。跨Sprint敏捷測試流程需要對不同Scrum團隊和不同Sprint的交付物進行整合和迴歸驗證測試，最終才能達到預釋出的狀態。

在整合的過程，主要還是依靠CI/CD流程，同時輔助人工探索式測試來實現。CI/CD為多個Scrum團隊的候選應用版本部署到系統或釋出整合環境中，同時會執行迴歸測試，驗證這些應用整合沒有問題並且透過人工的探索式測試後就能達到預釋出的狀態。

七、敏捷測試實踐轉變

在討論完文化、組織和流程後，下面我們繼續討論最後一個實踐部分。首先我們可以按照開發過程中程式碼推進路徑的先後順序分成不同的環節：

• 需求到配置庫
• 程式碼到開發環境
• 程式碼到Sprint測試環境
• 程式碼到整合/釋出測試環境
• 程式碼到生產環境

在這些環節中，程式碼從一個環節傳到下一個環節，它的質量應該會好些；再傳到再下一個環節，它的質量應該又更好些......一直到生產環節，使用者最終可以接收到一個質量可靠的產品。在這個過程中，這些環節就好像安置了一個“質量漏斗”，程式碼從一開始的輸入到最後的走向市場，經過質量漏斗的層層檢驗後，質量越來越好，直到最後程式碼被部署到生產環境推向市場。在生產上線後，還需要監控市場的接受度，收集並且確認來自使用者的反饋，把反饋推給內部的團隊作為新的輸入，以此就建立了一個反饋環，如圖5所示。

圖5 敏捷測試實踐框架

在質量漏斗中內建了不同環節的質量活動和賦能者來驅使質量的不斷提升。這些質量活動和賦能者不僅僅只在測試中才有，而是貫穿到整個開發過程中，這也是“質量內建”（Quality Build-in）的理念。

我們來看看不同的環節有什麼樣的質量活動和賦能者在其中：

• 需求到配置庫：這個環節是需求相關的環節，我們針對需求主要採用ATDD或者BDD的實踐進行活動，同時也要考慮關於可用性的調研，可以透過低保真原型向終端使用者收集反饋。該環節的賦能者是BDD的框架、ATDD的框架，比如Cucumber、Specflow等。
• 程式碼到開發環境：這個環節是單元測試環節，我們針對程式碼主要進行單元測試TDD、靜態程式碼分析、程式碼覆蓋率分析等活動。該環節的賦能者是XUnit框架、Jacoco程式碼覆蓋率分析、SonarQube靜態程式碼掃描等。
• 程式碼到Sprint測試環境：這個環節是Sprint內測試環節，我們針對程式碼的功能性和非功能性進行測試，主要的質量活動包括功能測試、效能測試、安全測試等。該環節的賦能者是服務虛擬化、API和UI的測試自動化、元件和故事級別的效能測試等。
• 程式碼到釋出整合測試環境：這個環節主要是跨Sprint的UAT測試環節，主要包括端到端聯調測試、探索式測試、效能測試、可用性/易用性測試、安全測試等活動。該環節的賦能者是自動化測試框架、CI/CD流水線、安全漏洞掃描、使用者體驗測試、系統級別的效能測試等。
• 程式碼到生產環境：這個環節主要是上線後環節，包括的質量活動如A/B測試、生產環境測試、混沌工程（Chaos Engineering）等。該環節的賦能者是自動化測試框架、生產監控工具包括APM等。

最後我們再看不同環節的測試工作量分佈。在程式碼向後推進的不同的環節中，我們的測試工作量是逐步減少的，這個也是和測試金字塔的理念一致的。

八、結語

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

• 透過敏捷測試流程使得測試過程與敏捷迭代一致，解決了測試時間短的問題；
• 透過合作伙伴式的客戶關係文化轉變，使得我們不再需要描寫繁雜的需求文件，我們透過與客戶頻繁溝通了解客戶的真正需要；
• 透過組織架構向跨職能團隊調整，質量應由團隊保障，解決了專職測試資源少的問題；
• 透過敏捷測試實踐的自動化測試與持續整合，縮減反饋週期，使得在變更頻繁的情況下也能很好的保證質量。
  

敏捷測試轉型不是一蹴而就的事情，需要組織持續不斷的堅持才能成功。敏捷測試轉型過程中也沒有一套放之四海而皆準的標準，所以轉型者也需要按照敏捷的方式小步進行、回顧評審、重新調整、再小步進行……相信透過這樣的方式成功一定會在不遠之處等著我們。

參考文獻

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