| 導讀 | 在大多數機構或公司裏，軟件開發過程主要遵循一個或多個開發模型，例如瀑布模型或敏捷模型。在瀑布模型中，測試活動一般都在後期進行。軟件開發完成後，缺陷被QA團隊找出，然後再被修復。後兩個活動不斷循環和重複，指導管理者認爲軟件可以被公開發布爲止。 |
如果你是一名軟件質量保障人員（QA），那麼是時候去找一份新的工作了（或者get新技能準備升級轉型）。絕大多數情況下，軟件開發過程包括如下幾個主要活動：
- 進行需求分析
- 創建軟件產品的規格說明書
- 構建軟件
- 軟件（或服務）質量調查
- 發現、修復缺陷
- 部署軟件到實際生產環境
在大多數機構或公司裏，軟件開發過程主要遵循一個或多個開發模型，例如瀑布模型或敏捷模型。在瀑布模型中，測試活動一般都在後期進行。軟件開發完成後，缺陷被QA團隊找出，然後再被修復。後兩個活動不斷循環和重複，指導管理者認爲軟件可以被公開發布爲止。
在敏捷模型中，包括QA在內的個人和團隊在一起緊密工作，在一種持續的基礎上不斷髮布、更新軟件，而在某個時間一起部署整個軟件。DevOps，就像我們在之前的文章中已經提到過的，是下一代的敏捷開發模型。敏捷是一種在軟件開發中不斷思考的方式，而DevOps則更進一步發展，是實現組織內開發哲學的具體開發文化的變革。
而且這種實現方式消除了QA作爲組織中一個單獨實體的存在意義，將質量保障的工作分散給不同的開發團隊，儘管許多人認爲原來的質量保障的規則仍然需要通過這種或其它的方式存在。
其中一種常見的觀點認爲DevOps位於開發團隊、運營團隊、QA團隊的中心（見上韋恩圖）：“一方面，QA團隊和開發團隊一起工作，儘量將他們的測試融入到系統的持續集成中。測試必須做到沒有人力干預，獨立產生他們自己的測試數據。另一方面，QA團隊和運營團隊一起合作完成監控工具，也可能一起不斷對產品進行Smoke Test。有一種可能是運營團隊在開發系統備份和恢復、部署回滾的腳本或者災難恢復的腳本。”
在NeoTYS的Tim Hinds則從不同的角度看待這個問題，他認爲“DevOps QA”的作用是預防缺陷的發生而不是檢測缺陷：“QA在組織中擔任非常關鍵的角色，因爲他們有足夠的能力和權限能夠在系統正常工作時將其發佈出去並且在發現系統不工作時將其回滾。這和10年前的QA團隊的觀念相比是非常不同的，當時認爲QA團隊的主要職責是發現缺陷。今天QA團隊則被要求避免缺陷被暴露給公衆。”
但是客觀的說，上述的觀點都是錯誤的。
DevOps通常使用持續集成（CI）和持續交付（CD）。在持續集成中，開發人員利用各種持續集成工具來不斷將代碼整合到共享代碼庫中，甚至每天多次提交，而且DevOps依賴自動化來確保版本質量。如果想要進行持續角度，就不能有人工干預，這樣才能確保在任何一個時間都可以發佈代碼庫中的任何一段代碼的任何一個版本。
基本上，傳統的QA不可能在完整的持續集成/持續交付的環境中工作。在舊的結構中，軟件產品的質量保障的責任是在QA的手裏、而今天，它則是DevOps的開發文化和開發哲學的一部分——所有開發人員都有這個責任而非僅僅組織中的一個獨立的團隊擁有這個責任。
具體來說，DevOps需要使用諸如BUGtrack、JIRA和Github等產品和工具來不斷彙總和報告軟件中的錯誤和缺陷。Selenium、Cucumber、Junit、TestNG和JMeter等自動測試工具則用於管理、執行和度量功能測試等。
最後總結一下，如果在開發團隊和運營團隊中間還阻隔了一層人員，那麼你就不能無縫執行持續集成和持續交付，也就不能進行DevOps。因此，要想正確的運行DevOps操作，則根本不能擁有（傳統型的）QA團隊。
那麼對於QA工作者來說他們之後會怎麼樣呢？作爲曾經美國最最幸福的工作之一的QA，隨着越來越多的組織使用DevOps，傳統型的QA工作者們的位置會變得越來越冗餘。
根據美國勞工統計局（BLS）的報告，軟件質量工程師是高新技術職業中增長速度預計將比平均水平慢的職業之一：
然而，美國勞工統計局的統計數字可能太泛化了因此勞工局還沒有將DevOps認定爲一個獨立的職業：
作爲證據，僅僅看一下Google趨勢中搜索數據的相對數量就會發現“sqa jobs”的搜索數量正在緩慢下降然而“devops jobs”的搜索數量則在迅速增長：
本文轉載自：http://www.linuxprobe.com/oa-to-devops.html
免費提供最新Linux技術教程書籍，爲開源技術愛好者努力做得更多更好：http://www.linuxprobe.com/