第一財經《最厲害靠譜的回本導師》GL團隊釋出

寫在前面：該專案是某企業CRM+ERP系統 0 - 1 的數字化轉型中最重要的一個產品之一，需要拉通上下游30+系統，有上百名的同事與我們共同在一線戰鬥。我們將專案上的實踐，遇到的問題，以及我們的辛酸苦辣落筆為大家眼前這些樸實的文字，希望能夠給大家帶來在大規模專案中做敏捷測試的不一樣體驗，感受大規模0到1數字化轉型中的QA的機遇與挑戰。

由於篇幅很長，將分成幾個部分陸續介紹給大家。這一篇先介紹專案中敏捷測試的基礎實踐。

敏捷方法已經在我司實踐落地多年，大多數的敏捷團隊是由10位以內不同角色的人員組建。其中包括但不僅限於BA、QA、UX、PM、DEV等關鍵角色。我們透過成熟的方法論以及stand up meeting

一、大規模敏捷測試的基礎：良好的敏捷實踐

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

大規模專案中，需要統一實施原則和節奏，定義主要的活動和規範。該專案採用的兩週一個迭代的方式，主要的活動包括：IKM，站會，開卡，DC，Showcase，回顧會等。每個活動中QA究竟如何補充質量視角呢？

運用IKM進行需求弄清，確保質量需求被辨認
每個迭代剛剛開始的時分會進行IKM，IKM階段BA弄清需求，團隊成員對齊瞭解，各自依據自己的視角發問，BA會對本迭代方針進行的弄清。
這兒QA必定要參加到IKM中來，假如精力滿足最好是能夠在IKM之前就預先了解需求，檢查檢驗標準，並從大局質量的視角提出問題。常見的問題包含是否考慮到Edge case，反常場景，和其他模組的共同性，效能，安全，第三方介面承認等。假如QA準備充足，乃至能夠對處理方案，架構等都提出質量相關質疑。

運用開卡進行驗證點弄清，確保對質量需求與開發瞭解共同
開卡階段由開卡的dev來drive，BA、QA參加。Dev說明自己對AC的瞭解和發問，弄清一些細節以及鴻溝。確保我們們瞭解的共同性。 QA除了能夠一同完善、弄清AC外，也能夠依據DC場景給出輸入，列一下比較重要的場景和check point，這樣開發能夠在做完卡自測的更加充分，也能夠DC條件前準備好測驗場景和資料。Dev在做卡的時分，會依據要完結的功用列tasking，這樣梳理清晰開發思路的一同也能讓其他人物更瞭解故事卡的完結細節。

運用站會對齊要害質量資訊
站會是靈敏實踐中的典型活動，每天固定時間15分鐘，我們們進行一個站會交流。可是在施行中，不同的團隊卻有不同的方法。有的團隊是以人為視角，每個人去更新自己昨天做了什麼，今天要做什麼，有什麼困難和阻礙。可是這樣的方法聚集在個人身上，無法形成全景圖。更新完之後我們們關於全體的進展和問題對大局的影響並沒有一個清晰的知道。後來團隊嘗試了以板子內容為中心，對不同狀況的卡片從右往左更新。之後再更新板子之外的工作，以及一些共性需求全體留意的問題。這種方法不只功率進步，我們們關於整個迭代都有了大局視角，假如在第二週有許多將要積壓的ready for QA的卡片，我們們會迅速達成共識，協助趕快完結。
QA要運用站會的時機引導我們們的質量意識，比方一些普遍的質量問題，一些嚴峻的質量問題以及質量危險都能夠透過站會傳遞這些要害資訊，強化團隊的質量意識。

推進開發質量內建
質量內建是我司的特色，也是質量確保的重要手法。在巨大的客戶進展壓力下，我們們開發小夥伴仍是保持了單元測驗乃至一部分介面測驗的實踐，覆蓋率達到60%-80%，為程式碼的質量增加了一層結實的防護網。一同每天固定時間的Code Review也是非常好的一個實踐，不只能夠對程式碼進行一個團隊評審，一同也是一個培訓新人，不斷強化程式碼標準的環節。
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小時修正等。可是也不太建議要求太死，畢竟這樣的衡量便是你要求什麼就會得到什麼。許多時分為了防止缺點延期，就把嚴峻的降級為一般的，反而使缺點記載失真，無法為後續測驗進步真實的資料參閱。
標準化的缺點辦理，能促進團隊各人物成員的參加和重視度，能有效地推進缺點的修正，能明晰的反應出各迭代缺點的實時動態，能為後續缺點剖析和開發質量的提升提供佐證和指明方向。我們們在後期整合階段，每日站會上透過缺點來進行整合中發現問題的各種資訊交流，有效地促進了問題的處理。一同也透過對缺點的剖析加強了同類問題的預防。

回憶會議
迴歸會議是非常重要的一個環節，它不只能夠讓我們們對過去一個迭代進行回憶，及時調整戰略，更重要的是它提供了一個時機或許說渠道，讓我們們能夠參加怎麼改善的定見，是賦予團隊每個成員主人翁意識的絕佳時機，特別關於平時話語權不多的QA同學，更是一個稀少難得的視窗來引導我們們的質量意識。惋惜許多團隊並沒有捉住這樣的一個時機。要麼因為時間緊，任務重就越過了這個環節，要麼是走方法，並沒有做到真實的考慮。
即便是有回憶會議，測驗人員假如沒有做準備，將質量透過資料，事情等迴歸的方法漸漸滲透，也很難運用這個時機。
惋惜的是這個專案中回憶會議並沒有履行的很到位。

一點感悟：除了選用靈敏的團隊，也有團隊選用小瀑布方法在同步開發其他的模組。儘管也選用兩週一個迭代的節奏，可是兩週內仍是迭代一切功用開發完結再交給測驗去測。沒有層層的需求弄清環節，比方開卡結卡這些不斷對齊需求的程式。常常聽到這些團隊的QA訴苦開發底子沒有了解需求就進行開發，導致許多返工。一同開發因為能力和頻寬問題，不願意做單元測驗，沒有質量內建意識，成果也是可想而知，他們開發的模組發現的問題高出2-3倍之多，更是常常改一個問題引入兩個問題。儘管開發不斷地加班，修bug速度驚人（曾經從正午到第二天早晨關掉30多個bug），但卻只能讓體系越來越軟弱，乃至在後期整合中迸發更多的問題。

二、大規劃靈敏測驗的中心：多團隊協作
一個小的團隊進行靈敏測驗實踐是比較可控的，QA很簡單取得大局觀，把控質量全景。可是當產品規劃和團隊規劃大到必定程度，即便沒有那麼複雜的架構，單是團隊之間的協作都要面對許多的應戰。大規劃靈敏最大的問題便是不同團隊之間的協作。疫情影響以及本錢的壓力，導致團隊成員散佈在多地，遠端的協作變成常態。怎麼防止遠端協作帶來的不方便，仍舊進行充分，高效地交流呢？

要害事情固定時間，防止浪費時間
固定時間進行開結卡，對應的角、色、BA、QA會預留開結卡時間，防止時間衝突約不到人導致的團隊空轉狀況。

奇妙運用東西及時傳遞資訊，推進事情流通
許多時分因為遠端，我們們很難面對面或許電話實時交流，即時資訊東西又會導致資訊刷屏，各種資訊交織。那怎麼能及時地傳遞關於某一個方面的資訊和定見呢？我們們能夠奇妙地運用東西。 每次交流的成果只需影響到其他成員或許人物，都會在對應的故事卡上comment進行記載。QA分診，做到資訊充分，防止多次交流。關於QA來講，遠端帶來的交流本錢要求對發現的問題做出更明確的分診，描繪缺點的時分要帶有場景，在什麼條件下，進行什麼操作，產生了什麼現象，介面有沒有對應的正確的或許過錯的返回值，有日誌的話給出日誌截圖，分派給對應故事卡的前端或後端。

運用即時通訊東西保持實時資訊通明
多個QA協作，共用服務佈置可能形成環境不穩定，這時就需求實時的資訊交流。 專案選用微服務架構，不同的組擔任維護不同的服務。當改動涉及到公共服務的時分，會有比較大範圍的影響。所以不能各自為營，需求各個組的QA進行通明的資訊辦理，當佈置公共服務的時分需求提前在資訊群中進行通知。對公共服務提供的介面要有清晰的瞭解，這樣在測驗程式能夠快速定位問題，一同也能及時透過CI的狀況掃除一些因為環境問題引起的缺點。

拆分依靠，視覺化依靠，對齊優先順序
專案規劃大，會有許多事務與其他模組的事務存在交集，功用存在互動。每個團隊都有自己擔任的模組，不同小組的開發進展和優先順序不同，這會導致小組之間存在功用或資料層面的相互依靠，從而引發對開發、測驗活動形成必定程度的block，這時分要BA/PM/TL與相關團隊和諧進展或許考慮運用mock的方法越過，並建立聯調卡顯現化依靠，並和各個模組對齊優先順序，待對應的模組ready後進行聯調。聯調之前需求儘量羅列聯調測驗需求的場景，等雙方都開發完結後，及時進行體系內部的聯調，測驗透過後，後續再有調整且會影響到其他模組的要及時同步，確保事務流的連貫性

介面證據留存，為介面改變做準備
因為所在的專案是0-1的全體數字化轉型，牽扯到多達十幾個產品一同上線，和第三方體系聯絡極為嚴密，許多整合的介面需求和其他體系的人對接，透過反覆評論才定義下來。這種狀況下必定要將對齊的成果以文字或許郵件方法儲存，即便是渠道上有資訊，也要額定備份，確保在後續有介面改變的時分有跡可循。不然在後續整合拉經程式中，介面的改變將帶來巨大的本錢和質量的危險。

QA驅動質量維度的團隊協作
作為團隊中的質量守護者，QA需求及時把控迭代進展，以免測驗時間被揉捏。而當測驗完結度存在危險的時分要及時跟團隊尋求協助，和諧資源。平時在各個環境中IKM，開卡結卡，Showcase時，將質量理念透過問題的方法不斷地給團隊小夥伴宣講，進步團隊的質量意識。當團隊中其他小夥伴有頻寬支撐測驗的時分，能夠更簡單地上手。QA能夠將測驗用例作為輸入，測驗點作為參閱給到團隊成員。一同依據不同人對不同事務的瞭解合理的安排工作，最大化的運用資源完結測驗。

一點感悟：在大規劃專案中團隊內部以及團隊間的協作是非常有應戰的，既要有一致的方針，標準，原則，又要滿足不同團隊的不同狀況，風格和文明。以上僅僅我在履行程式中的一些小的實踐，能夠針對不同的團隊風格進行不同的調整。最要害的是團隊協作必定要先一致方針，再符合標準，最後才是個性化的實踐。方針假如不能一致，標準不能符合，即便小團隊功率很高，也會為後期的整合埋下隱患。

因為篇幅較長，這次共享的是根底篇，後續我們們將陸續推出SIT整合篇，UAT檢驗篇等，敬請期待。

寫在後邊：這麼大規劃0-1數字化轉型也不太常見，參加其中有歡喜也有汗水，藉此共享給我們們，期望你能讀到一些不一樣的感悟。這個專案還處在比較原始的階段，即便有許多很好的很優秀的實踐，可是不見得就合適這個階段的旅程，所以假如你讀到了比較根底且常見的部分，也期望能夠了解在當下所選用的戰略。當然，必定有許多許多能夠改善和進步的地方，假如我們們有愛好也期望來一同評論最佳化。比方自動化，比方測驗戰略，比方… 歡迎我們們參加。