速度是新的貨幣
在過去的20年裏，軟件的開發方式發生了翻天覆地的變化，這已經不是什麼秘密了——而且變化的速度並沒有放慢。新的工具和技術不斷湧入，客戶的期望迅速跟上，預期軟件質量的默認水平每時每刻都在攀升。再加上日益複雜的體係結構，需要跨多個應用程序、層和團隊進行測試，測試經常成為瓶頸的原因就變得很清楚了。
市場已經證明，它更青睞那些能夠在不影響質量的情況下快速發布新功能的組織，而業務策略也相應地進行了調整。根據最近的一份報告，完全接受DevOps和敏捷實踐的組織的收入和利潤增長速度比主流組織高出60%，其業務增長速度超過20%的可能性是主流組織的2.4倍自由的動態調查．
但許多企業很快就會優先考慮交付速度，而將等式的質量方麵推到後麵。通常，測試成為最後一塊拚圖，即使軟件交付管道的其他部分已經現代化。的2020年Gitlab全球開發者調查發現盡管DevOps的交付速度提高了，但大多數DevOps團隊在測試階段遇到了大多數的延遲。
根據DORA的《2019加速DevOps狀態報告》在美國，被稱為“精英”的組織數量在2018年至2019年期間增加了近兩倍。這些精英團隊通過致力於持續的集成和交付實踐來“自動化一切”，其成功取決於有效的測試自動化。根據報告，“在構建自動化測試套件方麵的明智投資將有助於使CI更好。”
但隻要測試滯後，企業就會麵臨無法量化的風險。如果他們不能以更快的速度確保新產品的質量，他們也會否定快速創新的任何潛在好處。越來越多的證據表明，現代化的測試對於成功加速軟件交付是至關重要的。是時候開始測試轉型的想法了，是時候讓優秀的領導者扮演變革的代理人的角色了。
下麵的指南分享了我們關於在您的組織中率先進行測試轉換的建議——從開發並分享您對現代化測試實踐的願景，到獲得支持並推動整個組織的廣泛采用。
帶頭測試轉換:三步走的方法
無論您是支持一個組織範圍內的轉換，還是希望將測試實踐的一個關鍵方麵現代化，您的轉換工作都可能涉及以下所有或任何一個元素:
- 向敏捷測試過渡
- 擴展測試自動化
- 與DevOps管線集成
- 提高企業應用程序質量
- 支持雲遷移
- 提高數據完整性
- 軟件質量的其他方麵，無論是麵向客戶的，內部的，還是兩者兼而有之
當大多數組織開始調整他們的測試時，他們試圖在不延遲交付的情況下，接近提供可接受程度的風險覆蓋的最佳測試水平。
雖然新的工具集和過程可以幫助測試團隊朝著正確的方向前進，但是當我們討論推出測試轉換所需的更改時，隻有新的工具是不夠的。你需要一種全新的方法，以及持續的變革管理活動。
國際航空運輸協會(IATA)的測試經理道恩·霍爾(Dawn Hall)表示，這一切都要從戰略開始。她說:“如果你的測試策略是錯誤的，那麼工具就不能解決這個問題。”
在下麵的視頻中了解Dawn Hall是如何快速縮放測試自動化的。
在2018年1月，她啟動了一項重大的測試改革，將主要的手工過程轉變為精益測試方法，以更好地與組織不斷發展的業務模式保持一致。她的目標包括減少測試階段的數量，減少生產事故，減少測試期間的業務工作——所有這些都為DevOps管道的推出做出了貢獻。
如果你正在閱讀這篇文章，那麼你可能已經在你的組織中最具創新精神的團隊之一工作了。你可能可以想象，如果現代方法擴展到整個組織，它將產生的深遠影響。但是您如何將更改從第一個團隊擴展到10個、20個或100多個團隊呢?您需要一種可擴展的方法。
1.創造你的夢想
與業務保持一致
成功地實現現代化測試需要與更廣泛的業務策略保持一致，因此您應該做的第一個檢查是問自己是否存在這種情況，以及如何使這種聯係變得清晰。如果測試轉型對更廣泛的組織計劃的貢獻是不可否認的——無論是擴展DevOps、支持雲遷移，還是加速測試以支持新產品、業務渠道或收入流，那麼你將為你提出的測試轉型鋪平道路。
如果你的視野不清晰，你的旅程就不可能清晰
一個強大的願景將幫助你建立一個清晰的計劃，將工作塊分解成離散的任務。然後，你可以從任務中回過頭來，看看每一步對最終目標的貢獻。通常情況下，測試轉換不需要遵循敏捷或DevOps在業務中的其他地方的采用。
在一家大型金融科技公司在美國，是測試工程團隊領導了DevOps計劃，並引發了整個企業範圍的變革。在一次行業活動上關於DevOps的演講中，測試工程和交付加速副總裁受到啟發，開始向行業領袖和同行尋求建議，以了解DevOps的發布渠道，以及支持它們所需的測試策略。
隨著開發組織的敏捷轉型，Jones和他的團隊創建了一個卓越的跨職能QA中心，通過15個以上的運營DevOps管道向客戶交付軟件，將某些應用程序的測試時間、產品缺陷和部署時間從14小時減少到4分鍾。
清晰的願景是什麼樣的?
您的願景可以是對測試功能的徹底檢查，或者可以指向測試實踐的一個特定方麵。取例如,豐田，它對負載測試的現代化產生了重大影響。他們建立了一個卓越測試中心(TCoE)，其願景是:“提供、創新和協作解決方案，以推動內置的質量。”
豐田對質量的承諾由來已久，當他們的TCoE開始評估是否以及如何替換其遺留的負載測試工具時，他們總結出了推動其向前發展的主要因素:
- 測試需要向左移動，以滿足在開發周期中較早完成負載測試的需求，此時任何與性能有關的問題都更便宜、更容易修複
- 內部部署資源的維護成本很高，並且限製了可以執行的並行負載測試的數量
- 以前的工具不能滿足敏捷和DevOps的需求，因此在開發人員中采用的比例很低
- 測試長期處於開發周期的後期，造成了緊張的時間線，因為在需要將代碼推入生產環境之前，幾乎沒有時間修複問題
在在舊金山Tricentis Accelerate上的演講，豐田分享了他們如何向40個獨立團隊推出新的基於雲的負載測試解決方案。
當洲際酒店集團決定將TCoE中的測試人員聯合到開發團隊中時，他們創建了一份“全球質量工程雄心聲明”，以明確這一潛在的顛覆性變化背後的意圖和目標。該聲明確立了測試人員的承諾，即解決團隊的需求，傳播行業最佳實踐，優化測試實踐，並實施持續測試，以最終提高產品質量:
“持續的質量與速度。
-洲際酒店集團，全球質量工程抱負宣言
(我們的使命是)與商業和技術團隊合作，通過挑戰現狀，並引入創新的理念和技術來滿足他們的測試和質量工程需求，為他們創造可持續的價值。”
車間的想法
當你在發展你的願景時，要和不同的人驗證你的想法:它好嗎?它能撐得住嗎?這種改變真的有必要嗎?這是我們可能需要的改變嗎?隨著越來越多的人提供反饋，各種途徑將開始出現。利用這些不同的聲音來找出讓你的想法生根發芽的最佳方式。
雖然你可能會從一個小的控製小組開始，並會計劃一段時間的小規模行動，但你不希望自己的想法過早夭折，所以不要害怕從一開始就有一個遠大的願景。
練習向不同的利益相關者展示你的想法
為你需要從每一個利益相關者那裏聽到的問題準備答案。他們可能不會用這些確切的話，也不會那麼直接，但你要知道當你聽到:“這對我有什麼好處?”這是一個很好的練習，可以幫助您以具體的方式考慮轉換的影響。為什麼這種改變對那些受影響的人有價值?它會如何影響公司?您可能對積極的好處非常清楚，但您是否考慮過其他團隊可能麵臨的潛在陷阱或挑戰?
例如，當與開發人員交談時，你可以解釋說，質量文化意味著更少的熬夜、周末工作或趕在最後期限前重寫在sprint後期發現bug的代碼。為他們描繪一幅圖景——如果在開發周期的早期發現問題，你可以計算並顯示他們可以返回的時間。
當你第一次表達你的想法時，要注意保持平衡:你怎樣才能既傳達出想法的本質，又不過分簡化可能會阻礙你的挫折或障礙?你會渴望從你的談話對象那裏獲得支持，但如果他們後來覺得你忽視了成長的痛苦，那就會適得其反。
相反地，你應該期待收到一些挫折，或者聽到一些你沒有考慮到的潛在挫折。深入了解為什麼有人會抵製或拒絕提議，並計劃緩衝時間來應對艱難或冗長的討論。重大的改變總是伴隨著一定程度的成長痛苦，所以你不會想要回避這一點。接受需要重新設定的可能性，從一開始或更早的階段重新開始你的計劃。所有這些都會讓你的提案更有彈性。
2.獲得第一個支持者
當你練習和完善你的演講時，你可能會獲得你的第一批支持者，當你試圖為你的想法獲得足夠的動力時，你會得到一個支持者的基礎(或者至少是那些不是第一次聽到這個想法的同事)。當你的想法開始流行時，請記住以下幾點。
如果你在一個高度監管的行業工作，轉型可能會比較緩慢——在規劃和獲得支持時要有耐心。但事實上，在如此嚴格監管的環境中，缺陷的後果可能是重大的，這可能會加強你的案例。這篇文章分享采用測試優先的方法如何使工作在受管製環境中的團隊受益。
專注於贏得你的第一次和第二次勝利。然後口口相傳就會傳開。
-某全球製造商測試總監
學習如何毫不費力地建立測試的價值
注意不要落入“尋找漏洞”或“破壞產品”的常見陷阱。測試人員提供信息並幫助發現威脅產品價值或時間線的問題。優秀的測試人員可以在開發過程的早期完成這一點。測試人員不直接防止缺陷，但是他們的工作可以防止不知情和不知情的決定。
找到一個快速的項目，並獲得概念的證明
通過在公司內部收集真實的數據，你將為你的想法增加可信度，建立透明度，並展示采取更廣泛的行動可能是什麼樣子。如果你甚至在某種程度上能夠解決痛點，這是特別有效的。你需要組建一個小團隊，他們可以在一兩個sprint中嚐試一個小但切實的項目。
在Worldpay, QA主管Sandra Baker明白在組織的分布式敏捷團隊中會有不同的心態。為了促進新的自動化戰略的推出，她安排了一次路演，親自拜訪關鍵團隊，討論他們麵臨的獨特挑戰，並展示她的團隊早期的成功。貝克在以下視頻中分享了她的方法細節:
考慮尋找一個盟友——例如，一個產品經理，他可以幫助把想法變得更具體，用一種能與領導團隊的思考方式產生共鳴的語言來表達想法。開始的一種方法是考慮哪些測試術語更容易理解。
Robina Laughlin是Guardian敏捷測試轉型的先鋒，根據她的說法，與更廣泛的組織進行積極和頻繁的溝通是她成功的關鍵。“我們花了3-4個月的時間討論我們為什麼要這樣做，它意味著什麼，以及它將為團隊提供的機會，”勞克林說，她是Guardian的it質量管理助理副總裁。
她解釋說:“當我們在工作流程中引入新的變化時，我們提前計劃在我們更活躍的項目中找到良好的截止點，這樣每個人都知道什麼時候會發生變化。”
高管也是人
與尋找盟友類似，在項目的早期階段，尋找執行讚助者也是一種非常有力的支持方式。能夠回答:“這對我有什麼好處?以及“為什麼這樣做對公司最好?”在這裏至關重要。
根據澳新銀行測試高級經理Alex Kyriazis的說法，高管們首先會想要了解整體的好處，比如你是否降低了風險，或者是否提供了足夠的覆蓋範圍來有信心地部署代碼。你需要解釋你的指標所提供給他們的價值。
Kyriazis說:“比如你告訴一個c級主管，你每天晚上都有10萬個測試用例需要自動化，你現在交付軟件的速度更快了，或者你為他們節省了100萬美元。”但是所有的高管都知道，“你可能在錯誤的地方削減了100萬美元，或者設法將缺陷更快地交付到生產中。他們會想知道:‘那又怎樣?’”
高管們通常會以花費的美元和精力來說話，所以如果可以的話，找到一些硬數字來支持你的想法——比如如果所有測試都是手工進行的，所產生的成本，團隊生產力指標，或者團隊之間潛在的時間節約。溝通變更的好處，並對預期成本保持前瞻性和現實的態度。有了管理層的支持，您甚至可以快速通過一些常見的障礙，如新的培訓項目，或促進組織內的協作小組。
一旦你列出了主要的提議，根據客戶滿意度(成本、更新速度、有效性)將你的變更置於環境中，並將其與願景聯係起來。清晰的願景將在這裏幫助你，因為隨著你的旅程的展開，個人策略幾乎肯定會發生變化，並且在這些項目的過程中發生挫折和修改時，擁有清晰的願景將充當指南針。
盡早溝通行動和結果
提前通知同事，盡量減少他們對你的驚訝——你早期的小改變可能也意味著他們的改變。從積極的一麵來看，早期采用者往往有很多意見，所以很容易征求反饋。你也可以強調項目更容易在早期進行調整，所以在這個階段會特別感激你的關注。
根據芭芭拉多洲際酒店集團全球質量工程IT經理說:“沒有太多的溝通。過度溝通，永遠不會有壞處。”弗拉霍斯是采用和擴展敏捷的先鋒，她說她依靠多種渠道來傳達變化及其影響。“我們現在有市政廳、時事通訊、印刷傳單、用戶指南和常見問題解答，我們確保邀請每個人參加培訓。”
早期的結果，即使不是完全的成功，也不應該被隱藏起來。使用早期的數據點來解決和吸收經驗教訓，或者分享成功經驗，以消除任何可能有疑慮的利益相關者的疑慮。
3.建立動力和采用
第一個參與推動第一個改變的團隊可能由對該主題充滿熱情的人領導，並由精心挑選的愛好者組成團隊。不幸的是，第二個、第五個或第十個需要接受變更的團隊不太可能符合這個承諾水平，您需要考慮如何在不停頓的情況下擴展。
有沒有準備好應對失去勢頭的策略
要阻止一個有希望的變革，最快的方法之一就是在第一次失敗時感到灰心喪氣。這可能是一個抗拒的部門，不確定的概念證明，或缺乏管理支持。要知道這是過程的一部分，停下來重新評估，製定替代路線，或者隻是後退幾步，這並不一定意味著你的想法不值得追求。
為團隊成員創建一個記錄經驗教訓的中心位置。在構建願景的階段，從不同角色、不同目標的人那裏尋求反饋，在試圖理解為什麼某件事不成功時，會創造一個更全麵的參考。
在洲際酒店集團將測試管理現代化以實現敏捷對於每一個新加入的團隊，他們都準備好了“快速有效地應對”。在對每個團隊進行培訓之前，組織了一次預習會議，以了解他們獨特的工作流程，並確保他們不會感到更改是被迫的。
當他們遇到一個複雜用例的業務領域時，他們安排了與Tricentis的新一輪演示，在那裏這些團隊可以提供反饋並提交功能請求，讓他們參與到旅程中。通過透明地處理那些沒有發揮作用或沒有達到預期的領域，他們繼續推進轉型，而不是讓轉型陷入停滯。
收集度量標準
最吸引人的指標會因你所接觸的不同職能或級別的員工而不同。開發人員可能想知道:在sprint中，將一件物品從一個點移動到另一個點需要多長時間?發布和構建需要多長時間?測試需要多長時間?而工程副總裁則會對每個版本的風險覆蓋和進入市場的效率提高感興趣。
對於那些處於轉換工作第一線的人，以及那些每個月隻需要知道工作進展情況的人，度量標準可能也會有所不同。一定要考慮能夠讓團隊成員保持積極性的度量標準，以及能夠獲得轉換整體成功的緩慢移動的度量標準。
考慮講述一個測試故事——快速建立遠景，分享項目/產品的狀態，當前的漏洞是什麼，以及哪些潛在的失敗對客戶來說最重要。與本文中討論的許多其他方麵一樣，度量標準是項目的另一個方麵，您可能需要在這個過程中進行修改。
通過建立社區來采用。怎樣才能讓這種改變持續下去呢?
當您的變更進入一個穩定的階段時，考慮建立一個實踐社區，這個社區除了測試之外，還邀請業務用戶、產品經理、開發人員等等。在這個群體中創建輕鬆的知識分享空間，無論是活躍的Slack頻道、分享最新知識的午餐會議，還是定期的電話會議。
在整個組織中培養一小群擁護者(通常是早期采用者)，繼續監測、吸收和傳播你的事業。他們可以參與到上述實踐社區中，幫助保持培訓文檔的更新，或者成為更新和持續改進溝通的額外載體。
讓你的勝利成為領導團隊的勝利。如果你能獲得一個執行讚助人，這是特別有效的。承認因為領導的支持而創造的機會和支持。在質量是一種共同責任的組織文化中，測試的貢獻被理解，您將看到質量開始成為每個討論中不可分割的一部分。
穩定的采用是長期成功的最終關鍵，但它也需要最長的時間，所以要有耐心，要知道“新常態”將需要幾個周期才能成為新的默認。
測試轉換:為什麼是現在?
過去需要花時間建立開發基礎設施來構建新的功能和產品，而現在，新的環境或框架可以在幾分鍾內完成，為較小的參與者和團隊提供公平的競爭環境。雲計算、更加分布式的架構以及DevOps實踐的普及，為業界在速度和交付方麵提供了更大的靈活性。所有這些的融合意味著任何在轉型中忽略測試的組織都將被甩在後麵。
“作為一名領導者，我的工作並不一定是日常運營，而是比團隊提前12-18個月，這樣我就能向他們指明前進的道路。不要擔心你在這個過程中走了多遠，但要問問你是否為組織提供了價值，並保持領先於工程團隊。”
——亞曆克斯·Kyriazis澳新銀行測試高級經理
雖然發起數字化轉型似乎令人望而生畏，但不改變任何事情本身也是一個有後果的決定。轉變從微小的變化開始，最好被認為是一個持續的過程，是您日常工作的一部分。旅程永遠不會結束——所以要放眼未來，在前進的路上用裏程碑來衡量你的成功。