如果你聽取思想領(lǐng)袖的意見，QA 正在走向死亡。它毫無用處，而且很昂貴，此外，我們現(xiàn)在有機器可以做這些。根據(jù)我自己的經(jīng)驗，我已經(jīng)在沒有專門的 QA 團隊的組織中工作了幾年……我所說的轉(zhuǎn)型是質(zhì)量保證從開發(fā)的獨立最終階段轉(zhuǎn)變?yōu)楹诵碾A段。

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

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

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

我所說的轉(zhuǎn)型是指質(zhì)量保證從開發(fā)的獨立最終階段轉(zhuǎn)變?yōu)檐浖?chuàng)建的核心階段，每個開發(fā)人員都期望拆解自己的代碼以構(gòu)建更好的產(chǎn)品。如果你還沒有接受這種轉(zhuǎn)變，我有一個壞消息要告訴你。

為什么 QA 發(fā)生了變化

傳統(tǒng)的 QA 是這樣的：

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

圖片

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

圖片

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

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

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

在這個框架中，你會得到更慢的開發(fā)周期、更高的成本和潛在的質(zhì)量問題。所有這些都源于一個問題：在整個過程中需要更多地?fù)碛匈|(zhì)量。

質(zhì)量所有權(quán)的轉(zhuǎn)變

過去，QA 團隊是組織中質(zhì)量的仲裁者。現(xiàn)在，這種責(zé)任已經(jīng)轉(zhuǎn)移到了開發(fā)人員身上。這種轉(zhuǎn)變不僅僅是一個小的調(diào)整；它是對軟件質(zhì)量方法的根本性重構(gòu)。

我們上面提到的線性過程已轉(zhuǎn)變?yōu)闃?gòu)建、測試、重建和推送到生產(chǎn)的循環(huán)過程：

圖片

所有這些都發(fā)生在上面的開發(fā)框內(nèi)。開發(fā)人員現(xiàn)在是質(zhì)量控制的第一道防線。

這可以通過兩項舉措實現(xiàn)。

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

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

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

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

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

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

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

QA 的未來？

這會讓 QA 變得怎樣？

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

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

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

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

QA 現(xiàn)在掌握在個人及其工具手中

QA 團隊已經(jīng)消失，但質(zhì)量工程的思維方式將永遠(yuǎn)需要。這種思維方式現(xiàn)在已經(jīng)從特定的團隊轉(zhuǎn)變?yōu)槿谌朊總€從事產(chǎn)品開發(fā)的開發(fā)人員。組織現(xiàn)在必須找到方法，通過為他們提供生產(chǎn)高質(zhì)量軟件所需的工具和支持，來利用這種思維方式。

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