測試人員應該接受持續交付和持續部署，因為它們提供了成長和學習新技能的機會。

開發實踐在不斷變化，作為測試人員，我們必須擁抱變化。我們可以體驗到的變化之一是從每月或每季度發布到持續交付或持續部署的轉變。此外，這種向持續交付或部署的轉變為測試人員提供了學習新技能的機會。

每月或每季度發布的項目都有熟悉的節奏，并且團隊會朝著發布日期進行構建。測試人員必須測試所有的卡并進行手動回歸測試。手動腳本中的每個測試都需要執行，并且可能需要對這些測試的結果進行報告。發布后，發布中可能存在需要修復的錯誤。測試人員還需要在下一個版本上開始運行相同的手動回歸測試并再次報告。每月或每季度發布的測試是一個重復的過程。這個過程被比作希臘神話中的西西弗斯，他必須將一塊石頭滾到山頂，然后當石頭滾到山腳下時，他必須再次將它滾到山頂.

持續交付可以定義為“當所有開發人員都在主干上進行小批量工作時，......當主干保持在可發布狀態時，以及當我們按下按鈕就可以發布時”。與我合作的一個團隊從每月發布版本轉變為持續交付。該團隊將主要分支保持在可以根據需要進行部署的狀態，并且該團隊每周進行一次發布。持續部署可以定義為，除了支持持續交付的實踐之外，“我們通過自助服務（由 Dev 或 Ops 部署）定期將良好的構建部署到生產中”。每次代碼合并到主分支時，實踐持續部署的團隊都會部署到生產環境。

實踐持續交付或持續部署的團隊使用小批量。這意味著部署的“批次”代碼很小?！芭看笮〉睦碚撓孪奘菃渭?，其中每個單元一次執行一個”；這就是在持續部署中發生的情況，其中每次合并到主分支都會部署到生產環境中。

實踐持續交付和持續部署的團隊試圖以可持續的速度創建工作流程，因此應該“在日常工作中啟用和注入學習”。另一方面，每月發布版本的團隊都是為了發布而構建的，因此無法以可持續的速度創建這種持續的工作流程。

當團隊從每月發布轉向持續交付或持續部署時，發生的變化是沒有發布候選。未在候選發布版上進行測試；相反，它是在從主分支中取出的特性分支上完成的，當它們被合并回主分支時，它們必須準備好發布到生產環境中。主分支保持在可以發布到生產環境的狀態。對于測試人員來說，這意味著在功能分支上的測試與在發布候選上的測試具有不同的模式。

在功能分支上進行測試時，您需要確信功能分支中的新功能或修復會執行它應該執行的操作并且不會導致任何回歸。測試月度發布時，你可以有時間執行手動回歸測試，但如果主分支要保持可以部署到生產的狀態，這是不可能的。如果您使用持續交付或持續部署，回歸測試需要自動化。

每月發布的回歸測試通常包括運行大量手動測試；但是，如果您的團隊正在使用持續交付或持續部署，回歸測試通常會通過持續集成自動進行。持續集成 (CI)“意味著每次有人對代碼進行任何更改”，更改都會集成到代碼庫中。這需要在將代碼合并到主分支之前和之后運行自動化測試。這為測試人員提供了一個學習如何理解 CI 的機會。測試人員必須了解 CI，包括哪些測試作為 CI 的一部分運行。在 CI 上運行的測試總是會有差距。如果測試人員知道 CI 中的差距是什么，他們就可以想出如何自動化測試來填補這些差距，并在需要時執行手動測試來彌補差距。

測試人員也可以自己參與自動化回歸測試，通過這種方式，測試人員可以幫助防止錯誤而不是發現錯誤。有很多免費資源，例如測試自動化大學、LambdaTest 認證和 Exercism，它們可以幫助測試人員獲得自動化測試所需的技能。還有很多資源可以學習如何使用 javascript 來輔助測試。

回歸測試是自動化的，為測試人員創造了時間，他們可以花時間進行探索性測試。探索性測試是發現問題的有力方式，因此它將有助于測試人員正在進行的項目。有額外的時間做探索性測試也將幫助測試人員發展他們的探索性測試技能。

使用持續交付和持續部署的項目也往往具有微服務架構。微服務是有獨立測試和部署的服務，每個服務都很簡單。測試人員有機會了解微服務，方法包括與開發人員交談、研究現有的架構圖、閱讀 GitHub 中每個服務的自述文件以及參加開發人員會議。

測試人員可以通過幫助開發人員測試他們的代碼來建立他們與開發人員的關系。此外，測試人員可以與開發人員分享他們的測試技術知識，例如邊界值分析，因為這將有助于他們測試和生產質量更好的軟件。

每月發布的發布過程可能會給測試人員帶來一定的痛苦。有時我們被要求負責做出發布決定，即使測試人員通常是團隊中的初級成員；其他時候，測試人員必須參加由利益相關者組成的大型委員會會議，以決定是否可以發布軟件。持續部署和持續交付的發布過程應該是自動化的；這意味著發布不會給測試人員帶來壓力。測試人員在持續交付和持續部署中對發布的輸入是他們的測試；這意味著我們可以專注于測試并學習新的測試技能。

開發團隊不是自治的；它們是開放系統，其工作會影響其他團隊并受到其他團隊的影響。這就是系統思維，而系統思維有助于持續交付和持續部署。測試人員可以學習使用系統思維來增強他們的測試并支持他們的團隊。這可以幫助測試人員跳出他們的角色思考，以了解哪些其他系統受其團隊工作的影響以及哪些系統影響其團隊的工作。

系統思考的教訓之一是每個人都有責任，所以當出現問題時，任何人都不應受到指責。這個觀點也應該是每個實施持續交付或持續部署的敏捷和精益開發團隊的核心。這是測試人員應該學習并牢記在心的事情。當出現失敗時，我們需要從中吸取教訓，而不是責怪某人。

每月發布的團隊會發現，在每次發布之后，都會有一系列活動修復發布中部署的回歸錯誤。實踐持續交付或持續部署的團隊不會發生這種情況。發布將使用持續部署每天多次部署，軟件將通過持續交付定期部署。這些定期發布使開發團隊有機會快速從錯誤和事件中恢復，因為可以快速部署修復程序。部署修復程序后，測試人員可以主動提出帶頭進行根本原因分析，以找出錯誤或事件的根本原因。測試人員可以學習使用五個為什么和石川圖來進行根本原因分析。

測試人員還可以通過生成有助于團隊衡量質量改進的指標來支持團隊的工作。DORA 指標由 DORA 的 Accelerate State of DevOps 調查報告確定。這些指標旨在幫助實踐持續交付和持續部署的團隊找到需要改進的地方并了解他們的表現。這些與每月發布的指標不同，因為它們不是關于有多少錯誤已投入生產，而是關于團隊從錯誤中恢復的速度。

持續交付和持續部署為測試人員提供了成長和學習新技能的機會，因此當他們的團隊轉向持續交付和持續部署時，測試人員應該抓住機會。