作者 | 趙澤鑫，張海云，馮曌

大多數的敏捷團隊是由10位以內不同角色的人員組建。其中包括但不僅限于BA、QA、UX、PM、DEV等關鍵角色。我們通過成熟的方法論以及每日站立會議（Stand-up Meeting）、迭代計劃會議（Iteration Plan Meeting）、迭代啟動會議（Iteration Kickoff Meeting，IKM）、開卡（Kickoff）、結卡（Desk Check，DC）和回顧會議（Retrospective）等各種逐漸“標準化”的敏捷活動，能夠順利地運行一個小規模的項目。

然而，當項目規模逐漸增大、項目成員人數逐漸增加時，為了有效協作，我們需要將整個大規模團隊拆分為多個小規模的敏捷小組。但組與組之間的業務交互頻繁，組內以及組間的各種溝通交流，會讓原本快捷有效的敏捷活動變得繁瑣。

尤其對于測試來說，小規模的項目中一般配有一到兩名QA，負責所有功能模塊的測試工作。但大規模的項目中，QA不僅要關注本組內的功能，同時還要考慮組與組間存在關聯功能的測試。那么如何在高節奏的迭代中，進行大規模敏捷測試呢？

1. 大規模敏捷測試的基礎：良好的敏捷實踐

在大規模敏捷測試中，每個小組都需要貫徹執行良好的敏捷實踐，以保障每個模塊的高質量交付，從而獲得最終的高質量產品。在這些基礎敏捷實踐中，QA一直扮演著質量推動者的角色，不斷補充團隊的質量視角，保障每個小環節的交付質量，形成層層質量防護網。

在大規模項目中，為了保證執行效率和質量標準的一致性，我們需要統一實施原則和節奏，定義主要的活動和規范。該項目采用的是兩周一個迭代的方式，主要的活動包括：迭代開始會議（Iteration Kickoff Meeting，IKM）、站會（Stand-up Meeting）、開卡（Kickoff）、結卡（Desk Check）、階段性成果展示（Showcase）和回顧會議（Rstrospective）等。在每個活動中，QA可以通過以下方式補充質量視角：

利用IKM進行需求澄清，保障質量需求被識別

在每個迭代開始之前，團隊會進行IKM階段。在這個階段，BA會澄清需求，以確保團隊成員對目標有清晰的理解。同時，團隊成員也會從各自的視角提出問題，以對齊理解并確保團隊的一致性。此外，BA還將對本迭代目標進行澄清，以確保整個團隊都知道要實現什么目標，并為此共同努力。

在IKM階段中，QA的參與非常重要。如果QA的精力允許，最好能夠在IKM之前就預先熟悉需求，檢查驗收標準，并從全局質量的視角提出問題。常見的問題包括是否考慮到邊緣情況、異常場景和其他模塊的一致性，性能、安全和第三方接口的確認等。如果QA經驗充足，對系統的設計有全面了解的情況下，甚至可以對解決方案、架構等都提出質量相關質疑，以確保團隊在設計和實現過程中更加注重質量。

利用開卡（Kickoff）進行驗證點澄清，保障需求與開發理解一致

在開卡階段，由開卡的Dev來主導，BA和QA參與。Dev會說明自己對AC（Acceptance Criteria，驗收標準）的理解并提出問題，以澄清一些細節和邊界，確保團隊對需求的理解一致。除了可以與團隊一起完善和澄清AC外，QA還可以根據DC場景給出輸入，列出比較重要的場景和檢查點，以便Dev在完成開發后更充分的自測，也能夠在結卡前提前準備好測試場景和數據。Dev在開發的過程中，會根據要實現的功能列出任務清單，這樣可以梳理開發思路的同時也能讓其他角色更了解故事卡的實現細節。

利用站會對齊關鍵質量信息 

站會是敏捷實踐中的典型活動，每天固定時間15分鐘，大家進行一個站會溝通。但是在實施中，不同的團隊有不同的更新方式。一些團隊采用以人為視角的方式，每個人依次更新自己昨天完成的工作、今天要完成的工作以及遇到的問題和困難。這種方式比較適合多人協作完成一個大的任務，但對于多個任務卡片，每個卡片有不同的負責人的情況，比較難追蹤每個任務的進展和問題。

為了加強卡片進展的追蹤，我們團隊采用了以看板內容為中心，對不同狀態的卡片進行更新。之后再更新看板以外的事情，以及一些需要全體注意的問題。這種方式可以讓大家更清晰地了解每張卡的進度和問題，從而了解迭代的整體進度。例如，在迭代即將結束前幾天如果仍然有很多卡片在開發中，大家就可以迅速達成共識，加快結卡速度，為測試留出充足的時間。

QA要利用站會的機會引導大家的質量意識，比如一些普遍的質量問題，或者嚴重的質量問題以及質量風險都可以通過站會傳遞這些關鍵信息，強化團隊的質量意識。

推動開發質量內建 

質量內建是我司的特色，也是質量保障的重要手段。在面臨巨大的客戶進度壓力下，我們的開發團隊仍然堅持單元測試甚至一部分接口測試的實踐。這為代碼的質量增添了一層結實的保障。同時，每天固定時間的代碼審查也是非常有益的一個實踐。它不僅對代碼進行了團隊評審，同時也為新手提供了一個培訓環節，持續加強了代碼規范。

如果QA有時間和精力參與代碼評審，那將是一個很好地理解和學習代碼的機會，有助于QA更加精準地評估質量風險。

利用Desk Check（DC）進行需求實現澄清，識別風險點

Desk Check是由開發發起，BA和QA參與的活動。通過DC，我們重新審查AC，如果有額外場景需要演示，也可以直接進行演示。在此過程中，QA可以更深入地了解實現方案和風險點。在DC期間，QA也需要引導性地提出一些問題，以挖掘實現方案和代碼變動對其他功能的影響、交叉功能點的風險情況以及對其他模塊和產品的依賴和影響，從而為后續測試找到合適的方向。

故事卡測試

DC結束后，QA會進行故事卡的測試，故事卡測試一般采用根據AC驗證加探索性測試的形式。QA需要在開卡結束到DC的過程中根據故事卡的AC、邊緣場景以及自己對業務上下文的理解進行用例的編寫。

DC結束后QA要根據優先級以及業務的關聯性對故事卡進行功能測試，此外，還需進行必要的探索性測試，若在測試過程中，發現存在不能進行測試的集成測試場景，要記錄下來，在后續集成測試階段完成相關場景的測試。

利用Showcase與產品和業務進行澄清，并進行初步集成，檢驗質量內建成果

在大規模的項目中，Showcase是非常重要的環節。在關鍵節點上，對完成的關鍵功能進行Showcase，一方面可以極大地增加客戶的信心，讓他們真切地感受到階段性的成果，同時也可以收集一線業務用戶的反饋，便于我們進行及時的調整。

我們的Showcase包括迭代內的Showcase和milestone的Showcase兩種。迭代內的Showcase更注重細節和業務邏輯，從用戶側獲得反饋；Milestone階段的Showcase主要是面向客戶，更注重業務價值和系統邏輯與實際業務的貼合度。無論是哪種類型的Showcase，都需要注意收集反饋，并對有價值的修改和理解不一致的業務進行研究和討論，改進系統功能，使其更符合業務需求，產生更大的價值。

從質量的維度來說，Showcase意味著可以更早和其他模塊的初步集成，即使是為了跑通一個最基礎的場景，也需要經歷打包，初始化環境，部署，配置，初始化數據等環節。當初我們為了第一個showcase，部署SIT環境花了兩周的時間，經歷的各種問題還歷歷在目。但是它卻為開發提供了寶貴的可視化反饋，讓開發意識到配置管理（包括環境配置和參數配置）的重要性，接口設計的合理性等等，可以在后續開發中不斷地改進，為后續的持續集成打下一個堅實的基礎。

缺陷管理

缺陷管理針對測試過程中發現的問題，使用缺陷管理工具，進行統一規范管理。在敏捷開發中，許多團隊放棄了缺陷記錄，因為團隊規模小，直接溝通的方式就能夠快速傳遞上下文，修復問題，因此記錄缺陷會被認為是一種浪費。

然而，在大規模的敏捷測試中，我們仍然建議團隊對缺陷進行規范管理。在后期進行集成測試時，涉及多個模塊和產品，因此需要通過對缺陷的洞察，不斷地調整測試策略和方向。

在缺陷報告中必填信息包括不僅限于：缺陷的嚴重程度，修復優先級，發現階段，開發負責人，復現步驟，期望結果，缺陷當前狀態，缺陷類型以及發生的原因。此外，該項目中客戶對缺陷修復時長也有一定要求，例如阻塞缺陷要求當天修復，嚴重缺陷要求在24小時內修復等。

然而，我們不建議要求過于嚴格，畢竟這樣的度量就是你要求什么就會得到什么。很多時候為了避免缺陷延期，就把嚴重的降級為普通的，反而使缺陷記錄失真，無法為后續測試提高真實的數據參考。

規范化的缺陷管理能夠促進團隊各角色成員的參與和關注度，有效地推進缺陷的修復，并且明確反映出各個迭代缺陷的實時動態。此外，它還能為后續的缺陷分析和開發質量的提升提供佐證和指引方向。在后期的集成階段，我們每天的站會都會通過缺陷來交流集成測試中發現的問題信息，這有效地促進了問題的解決。同時，通過對缺陷進行分析，我們也加強了同類問題的預防。

回顧會議

回歸會議是非常重要的一個環節，它不僅可以讓大家對過去一個迭代進行回顧，及時調整策略，更重要的是它提供了一個機會或者平臺，讓大家可以參與如何改進的意見，是賦予團隊每個成員主人翁意識的絕佳時機?？上Ш芏鄨F隊并沒有抓住這樣的一個機會。要么因為時間緊，任務重就跳過了這個環節，要么是走形式，并沒有做到真正的思考。即使是有回顧會議，測試人員如果沒有做準備，將質量通過數據，事件等回歸的方式慢慢滲透，也很難利用這個機會。

2. 大規模敏捷測試的核心：多團隊協作

小規模團隊進行敏捷測試實踐是比較可控的，QA很容易獲得全局觀，把控質量全景。然而，當產品規模和團隊規模大到一定程度，即使沒有那么復雜的架構，僅僅是團隊之間的協作也會面臨諸多挑戰。大規模敏捷最大的問題就是不同團隊之間的協作。疫情的影響以及成本的壓力導致團隊成員分布在多地，遠程合作成為常態。如何避免遠程合作帶來的不便，同時仍然進行充分、高效的溝通呢？

為關鍵事件預留時間，避免浪費 

固定時間進行開卡、結卡，對應的角色BA、QA會預留開結卡時間，避免時間沖突約不到人導致的團隊空轉情況。

巧妙利用工具及時傳遞信息，推動事件流轉

由于遠程工作的原因，我們經常無法進行面對面或電話實時溝通，而即時信息工具又會導致信息刷屏，各種信息交織。那么如何才能及時地傳遞與某個方面相關的信息和意見呢？我們可以巧妙地利用工具。每次溝通的結果只要涉及其他成員或角色，就應在對應的故事卡中進行記錄。

QA應該進行分診，確保信息充分，避免多次溝通。對于QA來說，遠程工作帶來的溝通成本要求他們對發現的問題做出更明確的分診。在描述缺陷時，應該包括場景、操作、現象、接口是否返回正確或錯誤的值，并在有日志時提供截圖。然后將問題分派給相應故事卡的前端或后端。

利用即時通訊工具保持實時信息透明

多個QA協作，共用服務部署可能造成環境不穩定，這時就需要實時的信息溝通。項目采用微服務架構，不同的組負責維護不同的服務。當改動涉及公共服務的時候，會有比較大范圍的影響。所以不能各自為營，需要各個組的QA進行透明的信息管理，當部署公共服務的時候需要提前在信息群中進行通知。對公共服務提供的接口要有清晰的了解，這樣在測試過程能夠快速定位問題，同時也能及時通過CI的狀態排除一些由于環境問題引起的缺陷。

拆分依賴，可視化依賴，對齊優先級

在大型項目中，不同的業務和模塊之間存在交集和相互依賴，由于不同小組的開發進度和優先級不同，但是小組之間又會經常存在功能或數據層面的相互依賴，從而阻塞開發和測試活動，需要BA/PM/TL與相關團隊協調進度或者考慮使用mock的方式跳過，并建立聯調卡以顯示依賴，并與各個模塊對齊優先級。當對應的模塊準備就緒后，進行聯調之前需要盡量列舉聯調測試需要的場景。聯調之前需要盡量列舉聯調測試需要的場景，等雙方都開發完成后，及時進行系統內部的聯調，測試通過后，后續如果有調整并且會影響到其他模塊，則需要及時同步，以保證業務流的連貫性。

QA驅動質量維度的團隊協作

QA還可以通過QA驅動的方式來增強團隊的協作和質量意識。QA成員從需求評審開始就參與到項目中來，通過提前策劃測試方案、制定測試計劃、提供測試服務和評估測試結果等方式，來推動整個團隊的質量意識和測試水平。

QA需要及時把控迭代進度，以免測試時間被擠壓。而當測試完成度存在風險的時候，QA要及時跟團隊尋求幫助，協調資源。QA將質量理念通過問題的形式不斷地傳遞給團隊其他成員，提高團隊的質量意識。當團隊中其他小伙伴有帶寬支持測試的時候，QA可以將測試用例作為輸入，測試點作為參考給到團隊成員。同時根據不同人對不同業務的理解合理地安排工作，最大化地利用資源完成測試。

寫在最后

在大規模項目中實踐敏捷測試，團隊內部以及團隊間的協作是非常有挑戰的，既要有統一的目標，規范，原則，又要滿足不同團隊的不同情況，風格和文化。在實踐中，我們可以根據不同團隊的風格進行調整，以適應不同的情況。然而，最關鍵的是要先統一目標，再遵循規范，最后才是個性化的實踐。

如果目標不能統一，規范不能遵循，即使小團隊效率很高，也會為后期的集成埋下隱患。因此，在大規模項目中，我們需要加強團隊之間的溝通與交流，建立起良好的合作關系，確保每個團隊都能明確項目目標，并遵循相同的規范和原則。只有團隊內部有良好的敏捷實踐，同時加強團隊間溝通交流，大家都有統一明確的目標，才能取得項目的成功。