全球2000強企業越來越多地與準備顛覆行業的靈活的初創企業展開競爭。加速應用程序交付是保持競爭優勢的關鍵部分，但企業組織很難跟上。從複雜的應用程序棧(包括大型機、打包應用程序、幾十年前的自定義應用程序，以及現代接口)到為截然不同的交付模型構建的深層次流程，再到嚴格的遵從性需求，都給它們造成了負擔。有時，你好像在參加環法自行車賽，同時用自行車拖車拖著一個孩子。
通常情況下，是測試阻礙了應用程序的交付速度——特別是缺乏成熟的應用程序連續測試實踐提供關於應用程序是否具有可接受的業務風險級別的接近實時的反饋。沒有人懷疑持續測試的必要性。但是在任何開發環境中，讓它成為現實都是一個挑戰，在企業環境中，由於上麵提到的所有負擔和包袱，這是一個特別明顯的痛苦。
以下是企業在嚐試實施有效的連續測試實踐時通常麵臨的三個挑戰，以及頂級組織是如何解決它們的。這些連續不斷的測試故事都在Tricentis會議上公開展示。
1.引入並擴展測試自動化
擁有一組在引入業務風險時暴露業務風險的核心自動化測試，是持續測試的關鍵組件。然而,最新的世界質量報告發現,測試自動化多年來一直停滯在令人沮喪的15%左右。您不能，也不應該自動化所有的測試工作。但是，如果您希望獲得關於最新更改是否破壞了任何關鍵業務流程的快速反饋，那麼提高自動化是必不可少的。
問題是，開始自動化測試可能很困難，不幸的是，保持它的運行更加困難。大多數大型組織至少有一個或兩個失敗的測試自動化計劃，因此質量領導者不願意領導另一個測試自動化計劃，這是可以理解的。
然而，許多勇敢的QA領導者都在迎接挑戰並取得成功。他們的秘密是什麼?在較高的層次上，他們仍然專注於可持續的測試自動化的長期目標，因此他們構建了深層次的過程和文化變化來支持它。開始它需要找到一種測試自動化方法，該方法跨越您的業務過程中所涉及的各種技術(技術無關或廣泛的技術支持)，並且可以被您現有的團隊成員快速和廣泛地采用，無論他們當前的技能集可能是什麼。讓它繼續下去還需要解決我所謂的“測試自動化的三個噩夢”:測試維護、測試數據和測試環境。
以下是世界上最大的天然氣公司林德如何將測試自動化引入這家擁有100多年曆史的公司高度定製的SAP、Salesforce、web和移動應用程序的複雜網絡的一些技巧:
- 仔細考慮自動化將在哪些地方產生最大的影響，然後專注於為那些業務關鍵用例創建穩定的自動化。通過自動化少量高影響的端到端過程，您可以獲得更多的關注和內部支持，而不是通過自動化數千個構思不良的測試。
- 根除“測試數量”的思維模式。多年來，許多組織一直在使用一些測試來衡量測試的範圍，甚至補償測試提供者。針對相同的業務風險進行更多的測試並沒有幫助。事實上，它們很傷人。它們消耗創建資源和維護資源，侵蝕您的測試自動化ROI。
- 有時候你需要減少損失。如果一種方法或工具真的不適合你現有的資源(例如，它太技術或不適合你的生態係統)，了解需要什麼，並決心繼續解決它。
2.評估新功能的發布就緒情況
持續測試的主要目標是確定發布候選版本是否準備好投入生產。如上所述，您絕對需要確保每個版本中的更改不會破壞現有的功能。但您還需要測試新功能，以確保它能夠工作並滿足預期。
當不同的團隊負責應用程序的不同組件和層次時，做出最終的發布決定可能有點像猜謎遊戲:瀏覽器界麵、移動體驗、在幕後工作的各種打包應用程序(SAP、Salesforce、ServiceNow)，以及所有可能將它們粘合在一起的微服務、api和集成平台。他們可能會以不同的節奏開發新功能，以不同的方式測試他們的部分，使用不同的測試實踐和不同的工具。但是用戶不會區分這些區別。他們希望一切順利，完美無缺。
Moët軒尼詩-路易威登(LVMH)是Christian Dior、豪雅表(TAG Heuer)和唐培裏儂香檳王(Dom Perignon)等奢侈品牌的母公司，最近決定簡化測試流程，以支持其雄心勃勃的電子商務增長計劃。它完善了高效測試新功能的藝術，並製定了確保最終用戶體驗的發布決策:
- 采用結構化方法測試新功能。為了更好地保護客戶和品牌，每個QA團隊都深入研究了品牌的DNA及其核心客戶檔案(角色)。然後，他們開發了新的測試策略來檢查客戶對品牌的體驗，並將其捕獲為可重複使用的推出套件。
- 重用,重用,重用。他們構建了一個由戰略設計的測試構建塊組成的庫，能夠實現70-90%的跨啟動重用。這些構建塊映射到一係列測試自動化工具，它們結合起來查看、交互和評估站點，就像人類在各種各樣的設備上一樣。有了自動化的先機，他們可以在每個發布周期的早期開始測試，並在實現和改進新用戶故事時獲得快速的反饋。
- 連接這些點。所有針對網絡、移動、Salesforce電子商務、erp、倉庫和客戶關係管理係統等的不同測試數據，都集成到一塊玻璃中，通過角色、功能和技術層提供對發布準備情況的實時洞察。他們總是能一眼看出什麼準備發布，什麼阻礙了發布，以及誰負責讓它走上正軌。
3.平衡協作與自治
多年來，趨勢是向自治、自治的開發團隊發展，他們選擇最適合他們的文化和項目的實踐和工具。這對於團隊激勵非常好，但對於協作來說不是理想的。與此同時，另一個相互競爭的趨勢是高度互聯的應用程序，這使得協作變得更加重要。在交叉點上，有一個巨大的機會來共享測試工件以及代碼和部署工件。然而，這說起來容易做起來難，因為許多團隊已經習慣於使用他們自己的過程和測試工具。
你如何促進跨團隊的持續測試協作，而不將不同團隊在開發和完善中投入了大量資源的所有不同的工作方式同質化?戴爾已經製定了一個有效的戰略，利用跨30個部門的協同作用，跨20多個不同的測試自動化框架:
- 抽象是關鍵。他們從高層次的哲學角度分析了DevOps成功的要素，然後精心設計了一個抽象的CI/CD/CT架構，指定了要處理的活動(源代碼控製、需求管理、測試管理等)，而沒有規定如何完成這些活動的底層實現細節。
- 對於持續的測試，他們建立了一個覆蓋層，使他們能夠找到並運行相關的測試資產，甚至不需要考慮在幕後使用哪個測試自動化框架。這樣，每個人都可以分享，但沒有團隊必須妥協。
- 對於新項目，他們計劃標準化一個測試框架，這個測試框架足夠靈活，可以覆蓋各種應用程序堆棧和交付節奏。他們將使現有的團隊和項目可用，但沒有人被迫改變。
專注於正確的方法
沒有所謂的企業連續測試。正如你從這幾個例子中所看到的，最重要的挑戰和潛在的解決方案千差萬別，你也一樣。
要想成功，你需要現實一點。仔細仔細地看看你正在做的事情，然後製定相應的方法。不要期望長時間的手動測試人員下載一些開源測試工具，以及跨越打包應用程序、自定義應用程序、大型機等的自動化過程。同樣地，不要期望一個高性能的、精通技術的團隊放棄他們多年來投入大量時間和資源的自產或高度定製的軟件測試方法。
持續測試本身就是關於評估變更的影響。您進行持續測試的方法也必須圍繞變更構建:從技術、過程和變更管理的角度，您能做些什麼來簡化從您的當前狀態到企業持續測試過程的轉換，從而在質量、速度和效率方麵實現您組織的目標。
如果您想深入探討這些以及其他企業持續測試的挑戰，我邀請您閱讀我最近出版的書，企業持續測試:敏捷和DevOps的轉換測試．
*最初出現在新堆棧