如果你聽取思想領袖的意見，QA 正在走向死亡。它毫無用處，而且很昂貴，此外，我們現在有機器可以做這些。根據我自己的經驗，我已經在沒有專門的 QA 團隊的組織中工作了幾年……我所說的轉型是質量保證從開發的獨立最終階段轉變為核心階段。

譯自QA's Dead: Where Do We Go From Here?，作者 Kenn Hussey Ambassador Labs。譯者最近也與一位資深的測試（許多企業測試屬于QA）聊過，感覺測試的定位似乎越來越尷尬。

如果你聽取思想領袖的意見，QA 正在走向死亡。它毫無用處，它很昂貴，而且，我們現在有機器可以做這件事。根據我自己的經驗，我已經在沒有專門 QA 團隊的組織中工作了幾年，我認為世界其他地方終于趕上了。

如果我們對“QA 正在消亡嗎？”這個問題采用貝特里奇(Betteridge)標題定律的方法，不可避免的答案是否定的。QA 并沒有消亡；它已經死了。這種死亡已經對 QA 團隊產生了巨大的影響。然而，轉型已經發生，最終提高了軟件開發生命周期中質量的重要性。

我所說的轉型是指質量保證從開發的獨立最終階段轉變為軟件創建的核心階段，每個開發人員都期望拆解自己的代碼以構建更好的產品。如果你還沒有接受這種轉變，我有一個壞消息要告訴你。

為什么 QA 發生了變化

傳統的 QA 是這樣的：

• 設計：PM、架構師和開發人員定義產品需求并設計初始架構。
• 開發：開發人員根據需求和設計編寫代碼。
• 測試：QA 團隊接收完成的代碼，創建測試計劃和用例，并執行手動/自動化測試以涵蓋各種場景。他們將錯誤報告回開發團隊。
• 錯誤修復：開發人員接收錯誤報告，修復問題，并將代碼傳遞回 QA。
• 重新測試：QA 驗證修復并可能執行另一輪回歸測試。
• 發布：一旦 QA 批準，軟件將進入生產。

圖片

這種分隔的模型幾十年來一直是軟件開發的標準，但它已成為“扔過墻”心態的代名詞。編碼人員編碼，測試人員測試。但是，當像這樣列出來時，它很快就會清楚地表明問題是什么：

圖片

首先，每個人都被孤立了。開發和測試團隊獨立工作，導致溝通差距和期望不一致。這種分隔可能會導致一個很棒的產品，但會產生巨大的開銷。

其次，開發過程發生在任何實質性測試開始之前。這種后期錯誤發現可能效率更高。在開發周期早期發現的錯誤通常更容易修復且成本更低。然而，這種模型將錯誤檢測推遲到最后，增加了開發的總成本和時間。

第三，測試和錯誤修復之間的循環造成了嚴重的瓶頸。當發現錯誤時，它們會被返回給開發人員，修復，然后返回給 QA 進行重新測試。這種來回非常耗時，可能會延遲發布，尤其是在流程后期發現了重大問題。

在這個框架中，你會得到更慢的開發周期、更高的成本和潛在的質量問題。所有這些都源于一個問題：在整個過程中需要更多地擁有質量。

質量所有權的轉變

過去，QA 團隊是組織中質量的仲裁者。現在，這種責任已經轉移到了開發人員身上。這種轉變不僅僅是一個小的調整；它是對軟件質量方法的根本性重構。

我們上面提到的線性過程已轉變為構建、測試、重建和推送到生產的循環過程：

圖片

所有這些都發生在上面的開發框內。開發人員現在是質量控制的第一道防線。

這可以通過兩項舉措實現。

首先，迭代開發。敏捷方法意味著團隊現在以短周期工作，更頻繁地交付功能性軟件。這允許持續測試和反饋，在流程早期發現問題。這也意味著質量不再是最終的檢查點，而是在整個開發周期中持續考慮的因素。

其次，工具。自動化測試框架、CI/CD 流水線和代碼質量工具使開發人員能夠承擔更多質量控制責任，而不會冒倦怠的風險。這些工具允許對代碼質量進行即時反饋，對每次提交進行自動化測試，并將質量檢查集成到開發工作流程中。

在實踐中，這看起來像什么？

讓我們以全棧 API 開發為例。單個開發人員現在可以利用自動化大部分樣板工作的工具，并提供即時反饋。例如，這些工具使開發人員能夠執行以下操作：

• API 設計：開發人員現在可以快速創建標準化的 OpenAPI 規范。這使他們能夠幾乎立即開始編碼，而無需花費整個沖刺來構建初始設計。
• API 模擬：借助合適的工具，開發人員可以創建動態、可共享的模擬。這消除了手動編寫和維護模擬代碼的需要，從而實現快速驗證和迭代。
• 代碼生成：AI 驅動的代碼生成工具現在可以處理客戶端和服務器端 API 的大部分樣板代碼。這使開發人員能夠專注于 API 實現的獨特方面。
• 測試和調試：現代平臺提供公開可用的 URL 用于測試，使開發人員能夠在類似生產的環境中運行其代碼。這些直接與 IDE 集成，使開發人員能夠設置斷點并有效地調試，最大限度地減少錯誤進入生產環境的可能性。
• 部署：現在存在提供托管的、容器化的測試環境的工具。這允許輕松進行漸進式和重復測試，而無需不斷重新配置。

這些只是開發人員現在可以處理 API 開發和測試的許多方面的進步，這些方面以前是孤立的，或者需要與其他團隊進行大量來回溝通。

這種轉變并沒有消除對專業 QA 知識的需求。相反，它將質量考慮因素整合到整個開發過程中，開發人員承擔了更多責任，從一開始就確保其 API 的質量。

QA 的未來？

這會讓 QA 變得怎樣？

沒有家了嗎？有點，但也不完全是！更準確地說，他們現在有了多個家。QA 可以變得更具戰略性或更具技術性，向上或向下移動堆棧。

第一個機會是向下移動堆棧，進入更技術性的角色。QA 專業人員可以利用他們以質量為中心的思維方式成為自動化專家或 DevOps 工程師。他們在全面測試方面的專業知識對于開發健壯、可靠的自動化測試套件至關重要。“不穩定的測試比沒有測試更糟糕”的概念在測試是阻止組織發布低質量代碼的唯一手段時變得更加重要。

QA 擅長識別邊緣情況和潛在的故障點，這使得他們在創建全面的測試覆蓋范圍方面非常寶貴，而不僅僅是基本的正常路徑場景。這種嚴格性可以平衡快速開發環境中的任何YOLO 驅動的開發。

第二個機會是向上移動堆棧，進入戰略性角色。測試現在是開發生命周期中不可或缺的一部分，它需要思考。QA 專業人員可以發展成為質量策略師，專注于設計涵蓋整個軟件生命周期的全面測試策略。

QA 現在掌握在個人及其工具手中

QA 團隊已經消失，但質量工程的思維方式將永遠需要。這種思維方式現在已經從特定的團隊轉變為融入每個從事產品開發的開發人員。組織現在必須找到方法，通過為他們提供生產高質量軟件所需的工具和支持，來利用這種思維方式。

QA 的“消亡”最終不是關于它的消亡，而是關于它融入軟件開發的各個方面。組織面臨的挑戰將是培養一種文化，在這種文化中，質量是每個人的責任，同時仍然重視和利用 QA 專業人員帶來的專業技能。利用可以提供 QA 檢查的工具，并賦予您自己的開發人員每個人都戴上自己的 QA 帽子。