作者：ASAF YIGAL

翻譯：郝蕊（南京大學）

如果你是一名軟體質量保障人員（QA），那麼是時候去找一份新的工作了（或者get新技能準備升級轉型）。絕大多數情況下，軟體開發過程包括如下幾個主要活動：

• 進行需求分析
• 建立軟體產品的規格說明書
• 構建軟體
• 軟體（或服務）質量調查
• 發現、修復缺陷
• 部署軟體到實際生產環境

在大多數機構或公司裡，軟體開發過程主要遵循一個或多個開發模型，例如瀑布模型或敏捷模型。在瀑布模型中，測試活動一般都在後期進行。軟體開發完成後，缺陷被QA團隊找出，然後再被修復。後兩個活動不斷迴圈和重複，指導管理者認為軟體可以被公開發布為止。

在敏捷模型中，包括QA在內的個人和團隊在一起緊密工作，在一種持續的基礎上不斷髮布、更新軟體，而在某個時間一起部署整個軟體。DevOps，就像我們在之前的文章中已經提到過的，是下一代的敏捷開發模型。敏捷是一種在軟體開發中不斷思考的方式，而DevOps則更進一步發展，是實現組織內開發哲學的具體開發文化的變革。

而且這種實現方式消除了QA作為組織中一個單獨實體的存在意義，將質量保障的工作分散給不同的開發團隊，儘管許多人認為原來的質量保障的規則仍然需要通過這種或其它的方式存在。

過去對DevOps中QA的理解

其中一種常見的觀點認為DevOps位於開發團隊、運營團隊、QA團隊的中心（見上韋恩圖）：“一方面，QA團隊和開發團隊一起工作，儘量將他們的測試融入到系統的持續整合中。測試必須做到沒有人力干預，獨立產生他們自己的測試資料。另一方面，QA團隊和運營團隊一起合作完成監控工具，也可能一起不斷對產品進行Smoke Test。有一種可能是運營團隊在開發系統備份和恢復、部署回滾的指令碼或者災難恢復的指令碼。”

在NeoTYS的Tim Hinds則從不同的角度看待這個問題，他認為“DevOps QA”的作用是預防缺陷的發生而不是檢測缺陷：“QA在組織中擔任非常關鍵的角色，因為他們有足夠的能力和許可權能夠在系統正常工作時將其釋出出去並且在發現系統不工作時將其回滾。這和10年前的QA團隊的觀念相比是非常不同的，當時認為QA團隊的主要職責是發現缺陷。今天QA團隊則被要求避免缺陷被暴露給公眾。”

但是客觀的說，上述的觀點都是錯誤的。

為什麼DevOps不需要（傳統型的）QA

DevOps通常使用持續整合（CI）和持續交付（CD）。在持續整合中，開發人員利用各種持續整合工具來不斷將程式碼整合到共享程式碼庫中，甚至每天多次提交，而且DevOps依賴自動化來確保版本質量。如果想要進行持續角度，就不能有人工干預，這樣才能確保在任何一個時間都可以釋出程式碼庫中的任何一段程式碼的任何一個版本。

基本上，傳統的QA不可能在完整的持續整合/持續交付的環境中工作。在舊的結構中，軟體產品的質量保障的責任是在QA的手裡、而今天，它則是DevOps的開發文化和開發哲學的一部分——所有開發人員都有這個責任而非僅僅組織中的一個獨立的團隊擁有這個責任。

具體來說，DevOps需要使用諸如BUGtrack、JIRA和Github等產品和工具來不斷彙總和報告軟體中的錯誤和缺陷。Selenium、Cucumber、Junit、TestNG和JMeter等自動測試工具則用於管理、執行和度量功能測試等。

最後總結一下，如果在開發團隊和運營團隊中間還阻隔了一層人員，那麼你就不能無縫執行持續整合和持續交付，也就不能進行DevOps。因此，要想正確的執行DevOps操作，則根本不能擁有（傳統型的）QA團隊。

QA的未來

那麼對於QA工作者來說他們之後會怎麼樣呢？作為曾經美國最最幸福的工作之一的QA，隨著越來越多的組織使用DevOps，傳統型的QA工作者們的位置會變得越來越冗餘。

根據美國勞工統計局（BLS）的報告，軟體質量工程師是高新技術職業中增長速度預計將比平均水平慢的職業之一：

然而，美國勞工統計局的統計數字可能太泛化了因此勞工局還沒有將DevOps認定為一個獨立的職業：

作為證據，僅僅看一下Google趨勢中搜索資料的相對數量就會發現“sqa jobs”的搜尋數量正在緩慢下降然而“devops jobs”的搜尋數量則在迅速增長：

很明顯，QA的趨勢看起來絕對不算好。

文章來自微信公眾號：DevOps社群