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

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

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

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

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

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

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

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

圖片

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

圖片

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

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

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

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

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

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

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

圖片

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

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

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

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

在實(shí)踐中，這看起來像什么？

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

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

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

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

QA 的未來？

這會(huì)讓 QA 變得怎樣？

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

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

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

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

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

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

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