測試人員應(yīng)該接受持續(xù)交付和持續(xù)部署，因為它們提供了成長和學(xué)習(xí)新技能的機會。

開發(fā)實踐在不斷變化，作為測試人員，我們必須擁抱變化。我們可以體驗到的變化之一是從每月或每季度發(fā)布到持續(xù)交付或持續(xù)部署的轉(zhuǎn)變。此外，這種向持續(xù)交付或部署的轉(zhuǎn)變?yōu)闇y試人員提供了學(xué)習(xí)新技能的機會。

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

持續(xù)交付可以定義為“當(dāng)所有開發(fā)人員都在主干上進行小批量工作時，......當(dāng)主干保持在可發(fā)布狀態(tài)時，以及當(dāng)我們按下按鈕就可以發(fā)布時”。與我合作的一個團隊從每月發(fā)布版本轉(zhuǎn)變?yōu)槌掷m(xù)交付。該團隊將主要分支保持在可以根據(jù)需要進行部署的狀態(tài)，并且該團隊每周進行一次發(fā)布。持續(xù)部署可以定義為，除了支持持續(xù)交付的實踐之外，“我們通過自助服務(wù)（由 Dev 或 Ops 部署）定期將良好的構(gòu)建部署到生產(chǎn)中”。每次代碼合并到主分支時，實踐持續(xù)部署的團隊都會部署到生產(chǎn)環(huán)境。

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

實踐持續(xù)交付和持續(xù)部署的團隊試圖以可持續(xù)的速度創(chuàng)建工作流程，因此應(yīng)該“在日常工作中啟用和注入學(xué)習(xí)”。另一方面，每月發(fā)布版本的團隊都是為了發(fā)布而構(gòu)建的，因此無法以可持續(xù)的速度創(chuàng)建這種持續(xù)的工作流程。

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

在功能分支上進行測試時，您需要確信功能分支中的新功能或修復(fù)會執(zhí)行它應(yīng)該執(zhí)行的操作并且不會導(dǎo)致任何回歸。測試月度發(fā)布時，你可以有時間執(zhí)行手動回歸測試，但如果主分支要保持可以部署到生產(chǎn)的狀態(tài)，這是不可能的。如果您使用持續(xù)交付或持續(xù)部署，回歸測試需要自動化。

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

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

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

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

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

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

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

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

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

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

持續(xù)交付和持續(xù)部署為測試人員提供了成長和學(xué)習(xí)新技能的機會，因此當(dāng)他們的團隊轉(zhuǎn)向持續(xù)交付和持續(xù)部署時，測試人員應(yīng)該抓住機會。