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