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

大多數(shù)的敏捷團(tuán)隊(duì)是由10位以內(nèi)不同角色的人員組建。其中包括但不僅限于BA、QA、UX、PM、DEV等關(guān)鍵角色。我們通過成熟的方法論以及每日站立會(huì)議（Stand-up Meeting）、迭代計(jì)劃會(huì)議（Iteration Plan Meeting）、迭代啟動(dòng)會(huì)議（Iteration Kickoff Meeting，IKM）、開卡（Kickoff）、結(jié)卡（Desk Check，DC）和回顧會(huì)議（Retrospective）等各種逐漸“標(biāo)準(zhǔn)化”的敏捷活動(dòng)，能夠順利地運(yùn)行一個(gè)小規(guī)模的項(xiàng)目。

然而，當(dāng)項(xiàng)目規(guī)模逐漸增大、項(xiàng)目成員人數(shù)逐漸增加時(shí)，為了有效協(xié)作，我們需要將整個(gè)大規(guī)模團(tuán)隊(duì)拆分為多個(gè)小規(guī)模的敏捷小組。但組與組之間的業(yè)務(wù)交互頻繁，組內(nèi)以及組間的各種溝通交流，會(huì)讓原本快捷有效的敏捷活動(dòng)變得繁瑣。

尤其對(duì)于測試來說，小規(guī)模的項(xiàng)目中一般配有一到兩名QA，負(fù)責(zé)所有功能模塊的測試工作。但大規(guī)模的項(xiàng)目中，QA不僅要關(guān)注本組內(nèi)的功能，同時(shí)還要考慮組與組間存在關(guān)聯(lián)功能的測試。那么如何在高節(jié)奏的迭代中，進(jìn)行大規(guī)模敏捷測試呢？

1. 大規(guī)模敏捷測試的基礎(chǔ)：良好的敏捷實(shí)踐

在大規(guī)模敏捷測試中，每個(gè)小組都需要貫徹執(zhí)行良好的敏捷實(shí)踐，以保障每個(gè)模塊的高質(zhì)量交付，從而獲得最終的高質(zhì)量產(chǎn)品。在這些基礎(chǔ)敏捷實(shí)踐中，QA一直扮演著質(zhì)量推動(dòng)者的角色，不斷補(bǔ)充團(tuán)隊(duì)的質(zhì)量視角，保障每個(gè)小環(huán)節(jié)的交付質(zhì)量，形成層層質(zhì)量防護(hù)網(wǎng)。

在大規(guī)模項(xiàng)目中，為了保證執(zhí)行效率和質(zhì)量標(biāo)準(zhǔn)的一致性，我們需要統(tǒng)一實(shí)施原則和節(jié)奏，定義主要的活動(dòng)和規(guī)范。該項(xiàng)目采用的是兩周一個(gè)迭代的方式，主要的活動(dòng)包括：迭代開始會(huì)議（Iteration Kickoff Meeting，IKM）、站會(huì)（Stand-up Meeting）、開卡（Kickoff）、結(jié)卡（Desk Check）、階段性成果展示（Showcase）和回顧會(huì)議（Rstrospective）等。在每個(gè)活動(dòng)中，QA可以通過以下方式補(bǔ)充質(zhì)量視角：

利用IKM進(jìn)行需求澄清，保障質(zhì)量需求被識(shí)別

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

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

利用開卡（Kickoff）進(jìn)行驗(yàn)證點(diǎn)澄清，保障需求與開發(fā)理解一致

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

利用站會(huì)對(duì)齊關(guān)鍵質(zhì)量信息 

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

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

QA要利用站會(huì)的機(jī)會(huì)引導(dǎo)大家的質(zhì)量意識(shí)，比如一些普遍的質(zhì)量問題，或者嚴(yán)重的質(zhì)量問題以及質(zhì)量風(fēng)險(xiǎn)都可以通過站會(huì)傳遞這些關(guān)鍵信息，強(qiáng)化團(tuán)隊(duì)的質(zhì)量意識(shí)。

推動(dòng)開發(fā)質(zhì)量內(nèi)建 

質(zhì)量內(nèi)建是我司的特色，也是質(zhì)量保障的重要手段。在面臨巨大的客戶進(jìn)度壓力下，我們的開發(fā)團(tuán)隊(duì)仍然堅(jiān)持單元測試甚至一部分接口測試的實(shí)踐。這為代碼的質(zhì)量增添了一層結(jié)實(shí)的保障。同時(shí)，每天固定時(shí)間的代碼審查也是非常有益的一個(gè)實(shí)踐。它不僅對(duì)代碼進(jìn)行了團(tuán)隊(duì)評(píng)審，同時(shí)也為新手提供了一個(gè)培訓(xùn)環(huán)節(jié)，持續(xù)加強(qiáng)了代碼規(guī)范。

如果QA有時(shí)間和精力參與代碼評(píng)審，那將是一個(gè)很好地理解和學(xué)習(xí)代碼的機(jī)會(huì)，有助于QA更加精準(zhǔn)地評(píng)估質(zhì)量風(fēng)險(xiǎn)。

利用Desk Check（DC）進(jìn)行需求實(shí)現(xiàn)澄清，識(shí)別風(fēng)險(xiǎn)點(diǎn)

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

故事卡測試

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

DC結(jié)束后QA要根據(jù)優(yōu)先級(jí)以及業(yè)務(wù)的關(guān)聯(lián)性對(duì)故事卡進(jìn)行功能測試，此外，還需進(jìn)行必要的探索性測試，若在測試過程中，發(fā)現(xiàn)存在不能進(jìn)行測試的集成測試場景，要記錄下來，在后續(xù)集成測試階段完成相關(guān)場景的測試。

利用Showcase與產(chǎn)品和業(yè)務(wù)進(jìn)行澄清，并進(jìn)行初步集成，檢驗(yàn)質(zhì)量內(nèi)建成果

在大規(guī)模的項(xiàng)目中，Showcase是非常重要的環(huán)節(jié)。在關(guān)鍵節(jié)點(diǎn)上，對(duì)完成的關(guān)鍵功能進(jìn)行Showcase，一方面可以極大地增加客戶的信心，讓他們真切地感受到階段性的成果，同時(shí)也可以收集一線業(yè)務(wù)用戶的反饋，便于我們進(jìn)行及時(shí)的調(diào)整。

我們的Showcase包括迭代內(nèi)的Showcase和milestone的Showcase兩種。迭代內(nèi)的Showcase更注重細(xì)節(jié)和業(yè)務(wù)邏輯，從用戶側(cè)獲得反饋；Milestone階段的Showcase主要是面向客戶，更注重業(yè)務(wù)價(jià)值和系統(tǒng)邏輯與實(shí)際業(yè)務(wù)的貼合度。無論是哪種類型的Showcase，都需要注意收集反饋，并對(duì)有價(jià)值的修改和理解不一致的業(yè)務(wù)進(jìn)行研究和討論，改進(jìn)系統(tǒng)功能，使其更符合業(yè)務(wù)需求，產(chǎn)生更大的價(jià)值。

從質(zhì)量的維度來說，Showcase意味著可以更早和其他模塊的初步集成，即使是為了跑通一個(gè)最基礎(chǔ)的場景，也需要經(jīng)歷打包，初始化環(huán)境，部署，配置，初始化數(shù)據(jù)等環(huán)節(jié)。當(dāng)初我們?yōu)榱说谝粋€(gè)showcase，部署SIT環(huán)境花了兩周的時(shí)間，經(jīng)歷的各種問題還歷歷在目。但是它卻為開發(fā)提供了寶貴的可視化反饋，讓開發(fā)意識(shí)到配置管理（包括環(huán)境配置和參數(shù)配置）的重要性，接口設(shè)計(jì)的合理性等等，可以在后續(xù)開發(fā)中不斷地改進(jìn)，為后續(xù)的持續(xù)集成打下一個(gè)堅(jiān)實(shí)的基礎(chǔ)。

缺陷管理

缺陷管理針對(duì)測試過程中發(fā)現(xiàn)的問題，使用缺陷管理工具，進(jìn)行統(tǒng)一規(guī)范管理。在敏捷開發(fā)中，許多團(tuán)隊(duì)放棄了缺陷記錄，因?yàn)閳F(tuán)隊(duì)規(guī)模小，直接溝通的方式就能夠快速傳遞上下文，修復(fù)問題，因此記錄缺陷會(huì)被認(rèn)為是一種浪費(fèi)。

然而，在大規(guī)模的敏捷測試中，我們?nèi)匀唤ㄗh團(tuán)隊(duì)對(duì)缺陷進(jìn)行規(guī)范管理。在后期進(jìn)行集成測試時(shí)，涉及多個(gè)模塊和產(chǎn)品，因此需要通過對(duì)缺陷的洞察，不斷地調(diào)整測試策略和方向。

在缺陷報(bào)告中必填信息包括不僅限于：缺陷的嚴(yán)重程度，修復(fù)優(yōu)先級(jí)，發(fā)現(xiàn)階段，開發(fā)負(fù)責(zé)人，復(fù)現(xiàn)步驟，期望結(jié)果，缺陷當(dāng)前狀態(tài)，缺陷類型以及發(fā)生的原因。此外，該項(xiàng)目中客戶對(duì)缺陷修復(fù)時(shí)長也有一定要求，例如阻塞缺陷要求當(dāng)天修復(fù)，嚴(yán)重缺陷要求在24小時(shí)內(nèi)修復(fù)等。

然而，我們不建議要求過于嚴(yán)格，畢竟這樣的度量就是你要求什么就會(huì)得到什么。很多時(shí)候?yàn)榱吮苊馊毕菅悠?，就把?yán)重的降級(jí)為普通的，反而使缺陷記錄失真，無法為后續(xù)測試提高真實(shí)的數(shù)據(jù)參考。

規(guī)范化的缺陷管理能夠促進(jìn)團(tuán)隊(duì)各角色成員的參與和關(guān)注度，有效地推進(jìn)缺陷的修復(fù)，并且明確反映出各個(gè)迭代缺陷的實(shí)時(shí)動(dòng)態(tài)。此外，它還能為后續(xù)的缺陷分析和開發(fā)質(zhì)量的提升提供佐證和指引方向。在后期的集成階段，我們每天的站會(huì)都會(huì)通過缺陷來交流集成測試中發(fā)現(xiàn)的問題信息，這有效地促進(jìn)了問題的解決。同時(shí)，通過對(duì)缺陷進(jìn)行分析，我們也加強(qiáng)了同類問題的預(yù)防。

回顧會(huì)議

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

2. 大規(guī)模敏捷測試的核心：多團(tuán)隊(duì)協(xié)作

小規(guī)模團(tuán)隊(duì)進(jìn)行敏捷測試實(shí)踐是比較可控的，QA很容易獲得全局觀，把控質(zhì)量全景。然而，當(dāng)產(chǎn)品規(guī)模和團(tuán)隊(duì)規(guī)模大到一定程度，即使沒有那么復(fù)雜的架構(gòu)，僅僅是團(tuán)隊(duì)之間的協(xié)作也會(huì)面臨諸多挑戰(zhàn)。大規(guī)模敏捷最大的問題就是不同團(tuán)隊(duì)之間的協(xié)作。疫情的影響以及成本的壓力導(dǎo)致團(tuán)隊(duì)成員分布在多地，遠(yuǎn)程合作成為常態(tài)。如何避免遠(yuǎn)程合作帶來的不便，同時(shí)仍然進(jìn)行充分、高效的溝通呢？

為關(guān)鍵事件預(yù)留時(shí)間，避免浪費(fèi) 

固定時(shí)間進(jìn)行開卡、結(jié)卡，對(duì)應(yīng)的角色BA、QA會(huì)預(yù)留開結(jié)卡時(shí)間，避免時(shí)間沖突約不到人導(dǎo)致的團(tuán)隊(duì)空轉(zhuǎn)情況。

巧妙利用工具及時(shí)傳遞信息，推動(dòng)事件流轉(zhuǎn)

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

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

利用即時(shí)通訊工具保持實(shí)時(shí)信息透明

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

拆分依賴，可視化依賴，對(duì)齊優(yōu)先級(jí)

在大型項(xiàng)目中，不同的業(yè)務(wù)和模塊之間存在交集和相互依賴，由于不同小組的開發(fā)進(jìn)度和優(yōu)先級(jí)不同，但是小組之間又會(huì)經(jīng)常存在功能或數(shù)據(jù)層面的相互依賴，從而阻塞開發(fā)和測試活動(dòng)，需要BA/PM/TL與相關(guān)團(tuán)隊(duì)協(xié)調(diào)進(jìn)度或者考慮使用mock的方式跳過，并建立聯(lián)調(diào)卡以顯示依賴，并與各個(gè)模塊對(duì)齊優(yōu)先級(jí)。當(dāng)對(duì)應(yīng)的模塊準(zhǔn)備就緒后，進(jìn)行聯(lián)調(diào)之前需要盡量列舉聯(lián)調(diào)測試需要的場景。聯(lián)調(diào)之前需要盡量列舉聯(lián)調(diào)測試需要的場景，等雙方都開發(fā)完成后，及時(shí)進(jìn)行系統(tǒng)內(nèi)部的聯(lián)調(diào)，測試通過后，后續(xù)如果有調(diào)整并且會(huì)影響到其他模塊，則需要及時(shí)同步，以保證業(yè)務(wù)流的連貫性。

QA驅(qū)動(dòng)質(zhì)量維度的團(tuán)隊(duì)協(xié)作

QA還可以通過QA驅(qū)動(dòng)的方式來增強(qiáng)團(tuán)隊(duì)的協(xié)作和質(zhì)量意識(shí)。QA成員從需求評(píng)審開始就參與到項(xiàng)目中來，通過提前策劃測試方案、制定測試計(jì)劃、提供測試服務(wù)和評(píng)估測試結(jié)果等方式，來推動(dòng)整個(gè)團(tuán)隊(duì)的質(zhì)量意識(shí)和測試水平。

QA需要及時(shí)把控迭代進(jìn)度，以免測試時(shí)間被擠壓。而當(dāng)測試完成度存在風(fēng)險(xiǎn)的時(shí)候，QA要及時(shí)跟團(tuán)隊(duì)尋求幫助，協(xié)調(diào)資源。QA將質(zhì)量理念通過問題的形式不斷地傳遞給團(tuán)隊(duì)其他成員，提高團(tuán)隊(duì)的質(zhì)量意識(shí)。當(dāng)團(tuán)隊(duì)中其他小伙伴有帶寬支持測試的時(shí)候，QA可以將測試用例作為輸入，測試點(diǎn)作為參考給到團(tuán)隊(duì)成員。同時(shí)根據(jù)不同人對(duì)不同業(yè)務(wù)的理解合理地安排工作，最大化地利用資源完成測試。

寫在最后

在大規(guī)模項(xiàng)目中實(shí)踐敏捷測試，團(tuán)隊(duì)內(nèi)部以及團(tuán)隊(duì)間的協(xié)作是非常有挑戰(zhàn)的，既要有統(tǒng)一的目標(biāo)，規(guī)范，原則，又要滿足不同團(tuán)隊(duì)的不同情況，風(fēng)格和文化。在實(shí)踐中，我們可以根據(jù)不同團(tuán)隊(duì)的風(fēng)格進(jìn)行調(diào)整，以適應(yīng)不同的情況。然而，最關(guān)鍵的是要先統(tǒng)一目標(biāo)，再遵循規(guī)范，最后才是個(gè)性化的實(shí)踐。

如果目標(biāo)不能統(tǒng)一，規(guī)范不能遵循，即使小團(tuán)隊(duì)效率很高，也會(huì)為后期的集成埋下隱患。因此，在大規(guī)模項(xiàng)目中，我們需要加強(qiáng)團(tuán)隊(duì)之間的溝通與交流，建立起良好的合作關(guān)系，確保每個(gè)團(tuán)隊(duì)都能明確項(xiàng)目目標(biāo)，并遵循相同的規(guī)范和原則。只有團(tuán)隊(duì)內(nèi)部有良好的敏捷實(shí)踐，同時(shí)加強(qiáng)團(tuán)隊(duì)間溝通交流，大家都有統(tǒng)一明確的目標(biāo)，才能取得項(xiàng)目的成功。