第一財經《正規的大小單雙平臺網址》GL團隊釋出

寫在前面：該專案是某企業CRM+ERP體系 0 - 1 的數字化轉型中最重要的一個產品之一，需要拉通上下流30+體系，有上百名的搭檔與我們們共同在一線戰役。我們們將專案上的實踐，遇到的問題，以及我們們的辛酸苦辣落筆為我們眼前這些樸實的文字，期望能夠給我們帶來在大規劃專案中做靈敏測驗的不一樣體會，感觸大規劃0到1數字化轉型中的QA的機遇與挑戰。
因為篇幅很長，將分紅幾個部分連續介紹給我們。這一篇先介紹專案中靈敏測驗的基礎實踐。
靈敏方法已經在我司實踐落地多年，大多數的靈敏團隊是由10位以內不同人物的人員組成。其中包括但不只限於BA、QA、UX、PM、DEV等要害人物。我們們經過成熟的方法論以及stand up meeting、ipm、 ikm、kick off、desk check、retro等各種逐步“標準化“的靈敏活動，能夠順利地運轉一個小規劃的專案，但是當專案規劃逐步增大，專案成員人數逐步增加，將整個大規劃的團隊拆分為多個小規劃的靈敏小組後，因為組與組之間的業務互動頻頻，組內以及組間的各種溝通交流就會讓原本快捷有效的靈敏活動變得臃腫。特別關於測驗來說，小規劃的專案中一般配有一到兩名QA，負責所有功用模組的測驗作業。但大規劃的專案中，QA不只要重視本組內的功用，一同要考慮組與組間的存在相關功用的測驗。那麼如何在高節奏的迭代中，進行大規劃靈敏測驗呢？那就經過在某手機大廠的數字化轉型產品的測驗經向來和我們一同分享一下我的看法和感悟吧。

一、大規模靈敏測驗的根底：傑出的靈敏實踐
大規模靈敏測驗的根底是每個小組能夠貫徹執行傑出的靈敏實踐，保證每個模組的高質量交付，才幹取得最終的高質量產品。而在這根底靈敏實踐中，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數字化轉型也不太常見，參加其中有歡喜也有汗水，藉此共享給我們們，期望你能讀到一些不一樣的感悟。這個專案還處在比較原始的階段，即便有許多很好的很優異的實踐，可是不見得就適合這個階段的旅程，所以假如你讀到了比較根底且常見的部分，也期望能夠了解在當下所選用的戰略。當然，必定有許多許多能夠改善和進步的地方，假如我們們有興趣也期望來一同評論最佳化。比方自動化，比方測驗戰略，比方… 歡迎我們們加入。