建站
咨詢
售后
建站咨詢
新聞中心
作者 | 趙澤鑫，張海云，馮曌
大多數(shù)的敏捷團隊是由10位以內(nèi)不同角色的人員組建。其中包括但不僅限于BA、QA、UX、PM、DEV等關鍵角色。我們通過成熟的方法論以及每日站立會議（Stand-up Meeting）、迭代計劃會議（Iteration Plan Meeting）、迭代啟動會議（Iteration Kickoff Meeting，IKM）、開卡（Kickoff）、結卡（Desk Check，DC）和回顧會議（Retrospective）等各種逐漸“標準化”的敏捷活動，能夠順利地運行一個小規(guī)模的項目。
然而，當項目規(guī)模逐漸增大、項目成員人數(shù)逐漸增加時，為了有效協(xié)作，我們需要將整個大規(guī)模團隊拆分為多個小規(guī)模的敏捷小組。但組與組之間的業(yè)務交互頻繁，組內(nèi)以及組間的各種溝通交流，會讓原本快捷有效的敏捷活動變得繁瑣。
尤其對于測試來說，小規(guī)模的項目中一般配有一到兩名QA，負責所有功能模塊的測試工作。但大規(guī)模的項目中，QA不僅要關注本組內(nèi)的功能，同時還要考慮組與組間存在關聯(lián)功能的測試。那么如何在高節(jié)奏的迭代中，進行大規(guī)模敏捷測試呢？
1. 大規(guī)模敏捷測試的基礎：良好的敏捷實踐
在大規(guī)模敏捷測試中，每個小組都需要貫徹執(zhí)行良好的敏捷實踐，以保障每個模塊的高質(zhì)量交付，從而獲得最終的高質(zhì)量產(chǎn)品。在這些基礎敏捷實踐中，QA一直扮演著質(zhì)量推動者的角色，不斷補充團隊的質(zhì)量視角，保障每個小環(huán)節(jié)的交付質(zhì)量，形成層層質(zhì)量防護網(wǎng)。
在大規(guī)模項目中，為了保證執(zhí)行效率和質(zhì)量標準的一致性，我們需要統(tǒng)一實施原則和節(jié)奏，定義主要的活動和規(guī)范。該項目采用的是兩周一個迭代的方式，主要的活動包括：迭代開始會議（Iteration Kickoff Meeting，IKM）、站會（Stand-up Meeting）、開卡（Kickoff）、結卡（Desk Check）、階段性成果展示（Showcase）和回顧會議（Rstrospective）等。在每個活動中，QA可以通過以下方式補充質(zhì)量視角：
利用IKM進行需求澄清，保障質(zhì)量需求被識別
在每個迭代開始之前，團隊會進行IKM階段。在這個階段，BA會澄清需求，以確保團隊成員對目標有清晰的理解。同時，團隊成員也會從各自的視角提出問題，以對齊理解并確保團隊的一致性。此外，BA還將對本迭代目標進行澄清，以確保整個團隊都知道要實現(xiàn)什么目標，并為此共同努力。
在IKM階段中，QA的參與非常重要。如果QA的精力允許，最好能夠在IKM之前就預先熟悉需求，檢查驗收標準，并從全局質(zhì)量的視角提出問題。常見的問題包括是否考慮到邊緣情況、異常場景和其他模塊的一致性，性能、安全和第三方接口的確認等。如果QA經(jīng)驗充足，對系統(tǒng)的設計有全面了解的情況下，甚至可以對解決方案、架構等都提出質(zhì)量相關質(zhì)疑，以確保團隊在設計和實現(xiàn)過程中更加注重質(zhì)量。
利用開卡（Kickoff）進行驗證點澄清，保障需求與開發(fā)理解一致
在開卡階段，由開卡的Dev來主導，BA和QA參與。Dev會說明自己對AC（Acceptance Criteria，驗收標準）的理解并提出問題，以澄清一些細節(jié)和邊界，確保團隊對需求的理解一致。除了可以與團隊一起完善和澄清AC外，QA還可以根據(jù)DC場景給出輸入，列出比較重要的場景和檢查點，以便Dev在完成開發(fā)后更充分的自測，也能夠在結卡前提前準備好測試場景和數(shù)據(jù)。Dev在開發(fā)的過程中，會根據(jù)要實現(xiàn)的功能列出任務清單，這樣可以梳理開發(fā)思路的同時也能讓其他角色更了解故事卡的實現(xiàn)細節(jié)。
利用站會對齊關鍵質(zhì)量信息
站會是敏捷實踐中的典型活動，每天固定時間15分鐘，大家進行一個站會溝通。但是在實施中，不同的團隊有不同的更新方式。一些團隊采用以人為視角的方式，每個人依次更新自己昨天完成的工作、今天要完成的工作以及遇到的問題和困難。這種方式比較適合多人協(xié)作完成一個大的任務，但對于多個任務卡片，每個卡片有不同的負責人的情況，比較難追蹤每個任務的進展和問題。
為了加強卡片進展的追蹤，我們團隊采用了以看板內(nèi)容為中心，對不同狀態(tài)的卡片進行更新。之后再更新看板以外的事情，以及一些需要全體注意的問題。這種方式可以讓大家更清晰地了解每張卡的進度和問題，從而了解迭代的整體進度。例如，在迭代即將結束前幾天如果仍然有很多卡片在開發(fā)中，大家就可以迅速達成共識，加快結卡速度，為測試留出充足的時間。
QA要利用站會的機會引導大家的質(zhì)量意識，比如一些普遍的質(zhì)量問題，或者嚴重的質(zhì)量問題以及質(zhì)量風險都可以通過站會傳遞這些關鍵信息，強化團隊的質(zhì)量意識。
推動開發(fā)質(zhì)量內(nèi)建
質(zhì)量內(nèi)建是我司的特色，也是質(zhì)量保障的重要手段。在面臨巨大的客戶進度壓力下，我們的開發(fā)團隊仍然堅持單元測試甚至一部分接口測試的實踐。這為代碼的質(zhì)量增添了一層結實的保障。同時，每天固定時間的代碼審查也是非常有益的一個實踐。它不僅對代碼進行了團隊評審，同時也為新手提供了一個培訓環(huán)節(jié)，持續(xù)加強了代碼規(guī)范。
如果QA有時間和精力參與代碼評審，那將是一個很好地理解和學習代碼的機會，有助于QA更加精準地評估質(zhì)量風險。
利用Desk Check（DC）進行需求實現(xiàn)澄清，識別風險點
Desk Check是由開發(fā)發(fā)起，BA和QA參與的活動。通過DC，我們重新審查AC，如果有額外場景需要演示，也可以直接進行演示。在此過程中，QA可以更深入地了解實現(xiàn)方案和風險點。在DC期間，QA也需要引導性地提出一些問題，以挖掘?qū)崿F(xiàn)方案和代碼變動對其他功能的影響、交叉功能點的風險情況以及對其他模塊和產(chǎn)品的依賴和影響，從而為后續(xù)測試找到合適的方向。
故事卡測試
DC結束后，QA會進行故事卡的測試，故事卡測試一般采用根據(jù)AC驗證加探索性測試的形式。QA需要在開卡結束到DC的過程中根據(jù)故事卡的AC、邊緣場景以及自己對業(yè)務上下文的理解進行用例的編寫。
DC結束后QA要根據(jù)優(yōu)先級以及業(yè)務的關聯(lián)性對故事卡進行功能測試，此外，還需進行必要的探索性測試，若在測試過程中，發(fā)現(xiàn)存在不能進行測試的集成測試場景，要記錄下來，在后續(xù)集成測試階段完成相關場景的測試。
利用Showcase與產(chǎn)品和業(yè)務進行澄清，并進行初步集成，檢驗質(zhì)量內(nèi)建成果
在大規(guī)模的項目中，Showcase是非常重要的環(huán)節(jié)。在關鍵節(jié)點上，對完成的關鍵功能進行Showcase，一方面可以極大地增加客戶的信心，讓他們真切地感受到階段性的成果，同時也可以收集一線業(yè)務用戶的反饋，便于我們進行及時的調(diào)整。
我們的Showcase包括迭代內(nèi)的Showcase和milestone的Showcase兩種。迭代內(nèi)的Showcase更注重細節(jié)和業(yè)務邏輯，從用戶側獲得反饋；Milestone階段的Showcase主要是面向客戶，更注重業(yè)務價值和系統(tǒng)邏輯與實際業(yè)務的貼合度。無論是哪種類型的Showcase，都需要注意收集反饋，并對有價值的修改和理解不一致的業(yè)務進行研究和討論，改進系統(tǒng)功能，使其更符合業(yè)務需求，產(chǎn)生更大的價值。
從質(zhì)量的維度來說，Showcase意味著可以更早和其他模塊的初步集成，即使是為了跑通一個最基礎的場景，也需要經(jīng)歷打包，初始化環(huán)境，部署，配置，初始化數(shù)據(jù)等環(huán)節(jié)。當初我們?yōu)榱说谝粋€showcase，部署SIT環(huán)境花了兩周的時間，經(jīng)歷的各種問題還歷歷在目。但是它卻為開發(fā)提供了寶貴的可視化反饋，讓開發(fā)意識到配置管理（包括環(huán)境配置和參數(shù)配置）的重要性，接口設計的合理性等等，可以在后續(xù)開發(fā)中不斷地改進，為后續(xù)的持續(xù)集成打下一個堅實的基礎。
缺陷管理
缺陷管理針對測試過程中發(fā)現(xiàn)的問題，使用缺陷管理工具，進行統(tǒng)一規(guī)范管理。在敏捷開發(fā)中，許多團隊放棄了缺陷記錄，因為團隊規(guī)模小，直接溝通的方式就能夠快速傳遞上下文，修復問題，因此記錄缺陷會被認為是一種浪費。
然而，在大規(guī)模的敏捷測試中，我們?nèi)匀唤ㄗh團隊對缺陷進行規(guī)范管理。在后期進行集成測試時，涉及多個模塊和產(chǎn)品，因此需要通過對缺陷的洞察，不斷地調(diào)整測試策略和方向。
在缺陷報告中必填信息包括不僅限于：缺陷的嚴重程度，修復優(yōu)先級，發(fā)現(xiàn)階段，開發(fā)負責人，復現(xiàn)步驟，期望結果，缺陷當前狀態(tài)，缺陷類型以及發(fā)生的原因。此外，該項目中客戶對缺陷修復時長也有一定要求，例如阻塞缺陷要求當天修復，嚴重缺陷要求在24小時內(nèi)修復等。
然而，我們不建議要求過于嚴格，畢竟這樣的度量就是你要求什么就會得到什么。很多時候為了避免缺陷延期，就把嚴重的降級為普通的，反而使缺陷記錄失真，無法為后續(xù)測試提高真實的數(shù)據(jù)參考。
規(guī)范化的缺陷管理能夠促進團隊各角色成員的參與和關注度，有效地推進缺陷的修復，并且明確反映出各個迭代缺陷的實時動態(tài)。此外，它還能為后續(xù)的缺陷分析和開發(fā)質(zhì)量的提升提供佐證和指引方向。在后期的集成階段，我們每天的站會都會通過缺陷來交流集成測試中發(fā)現(xiàn)的問題信息，這有效地促進了問題的解決。同時，通過對缺陷進行分析，我們也加強了同類問題的預防。
回顧會議
回歸會議是非常重要的一個環(huán)節(jié)，它不僅可以讓大家對過去一個迭代進行回顧，及時調(diào)整策略，更重要的是它提供了一個機會或者平臺，讓大家可以參與如何改進的意見，是賦予團隊每個成員主人翁意識的絕佳時機?？上Ш芏鄨F隊并沒有抓住這樣的一個機會。要么因為時間緊，任務重就跳過了這個環(huán)節(jié)，要么是走形式，并沒有做到真正的思考。即使是有回顧會議，測試人員如果沒有做準備，將質(zhì)量通過數(shù)據(jù)，事件等回歸的方式慢慢滲透，也很難利用這個機會。
2. 大規(guī)模敏捷測試的核心：多團隊協(xié)作
小規(guī)模團隊進行敏捷測試實踐是比較可控的，QA很容易獲得全局觀，把控質(zhì)量全景。然而，當產(chǎn)品規(guī)模和團隊規(guī)模大到一定程度，即使沒有那么復雜的架構，僅僅是團隊之間的協(xié)作也會面臨諸多挑戰(zhàn)。大規(guī)模敏捷最大的問題就是不同團隊之間的協(xié)作。疫情的影響以及成本的壓力導致團隊成員分布在多地，遠程合作成為常態(tài)。如何避免遠程合作帶來的不便，同時仍然進行充分、高效的溝通呢？
為關鍵事件預留時間，避免浪費
固定時間進行開卡、結卡，對應的角色BA、QA會預留開結卡時間，避免時間沖突約不到人導致的團隊空轉情況。
巧妙利用工具及時傳遞信息，推動事件流轉
由于遠程工作的原因，我們經(jīng)常無法進行面對面或電話實時溝通，而即時信息工具又會導致信息刷屏，各種信息交織。那么如何才能及時地傳遞與某個方面相關的信息和意見呢？我們可以巧妙地利用工具。每次溝通的結果只要涉及其他成員或角色，就應在對應的故事卡中進行記錄。
QA應該進行分診，確保信息充分，避免多次溝通。對于QA來說，遠程工作帶來的溝通成本要求他們對發(fā)現(xiàn)的問題做出更明確的分診。在描述缺陷時，應該包括場景、操作、現(xiàn)象、接口是否返回正確或錯誤的值，并在有日志時提供截圖。然后將問題分派給相應故事卡的前端或后端。
利用即時通訊工具保持實時信息透明
多個QA協(xié)作，共用服務部署可能造成環(huán)境不穩(wěn)定，這時就需要實時的信息溝通。項目采用微服務架構，不同的組負責維護不同的服務。當改動涉及公共服務的時候，會有比較大范圍的影響。所以不能各自為營，需要各個組的QA進行透明的信息管理，當部署公共服務的時候需要提前在信息群中進行通知。對公共服務提供的接口要有清晰的了解，這樣在測試過程能夠快速定位問題，同時也能及時通過CI的狀態(tài)排除一些由于環(huán)境問題引起的缺陷。
拆分依賴，可視化依賴，對齊優(yōu)先級
在大型項目中，不同的業(yè)務和模塊之間存在交集和相互依賴，由于不同小組的開發(fā)進度和優(yōu)先級不同，但是小組之間又會經(jīng)常存在功能或數(shù)據(jù)層面的相互依賴，從而阻塞開發(fā)和測試活動，需要BA/PM/TL與相關團隊協(xié)調(diào)進度或者考慮使用mock的方式跳過，并建立聯(lián)調(diào)卡以顯示依賴，并與各個模塊對齊優(yōu)先級。當對應的模塊準備就緒后，進行聯(lián)調(diào)之前需要盡量列舉聯(lián)調(diào)測試需要的場景。聯(lián)調(diào)之前需要盡量列舉聯(lián)調(diào)測試需要的場景，等雙方都開發(fā)完成后，及時進行系統(tǒng)內(nèi)部的聯(lián)調(diào)，測試通過后，后續(xù)如果有調(diào)整并且會影響到其他模塊，則需要及時同步，以保證業(yè)務流的連貫性。
QA驅(qū)動質(zhì)量維度的團隊協(xié)作
QA還可以通過QA驅(qū)動的方式來增強團隊的協(xié)作和質(zhì)量意識。QA成員從需求評審開始就參與到項目中來，通過提前策劃測試方案、制定測試計劃、提供測試服務和評估測試結果等方式，來推動整個團隊的質(zhì)量意識和測試水平。
QA需要及時把控迭代進度，以免測試時間被擠壓。而當測試完成度存在風險的時候，QA要及時跟團隊尋求幫助，協(xié)調(diào)資源。QA將質(zhì)量理念通過問題的形式不斷地傳遞給團隊其他成員，提高團隊的質(zhì)量意識。當團隊中其他小伙伴有帶寬支持測試的時候，QA可以將測試用例作為輸入，測試點作為參考給到團隊成員。同時根據(jù)不同人對不同業(yè)務的理解合理地安排工作，最大化地利用資源完成測試。
寫在最后
在大規(guī)模項目中實踐敏捷測試，團隊內(nèi)部以及團隊間的協(xié)作是非常有挑戰(zhàn)的，既要有統(tǒng)一的目標，規(guī)范，原則，又要滿足不同團隊的不同情況，風格和文化。在實踐中，我們可以根據(jù)不同團隊的風格進行調(diào)整，以適應不同的情況。然而，最關鍵的是要先統(tǒng)一目標，再遵循規(guī)范，最后才是個性化的實踐。
如果目標不能統(tǒng)一，規(guī)范不能遵循，即使小團隊效率很高，也會為后期的集成埋下隱患。因此，在大規(guī)模項目中，我們需要加強團隊之間的溝通與交流，建立起良好的合作關系，確保每個團隊都能明確項目目標，并遵循相同的規(guī)范和原則。只有團隊內(nèi)部有良好的敏捷實踐，同時加強團隊間溝通交流，大家都有統(tǒng)一明確的目標，才能取得項目的成功。
本文標題：大規(guī)模敏捷測試怎么做（基礎篇）
當前鏈接：http://m.5511xx.com/article/cdidsgg.html
