前幾天看爬文的時候看到了這篇《shift left and shift right: the testing swing》，裡面描述了一些測試左移和測試右移的思路和方法，覺得有一定的啟發，可以分享一下。
作者站在專案或者產研發負責人的角度闡述了自己團隊在敏捷及devops中的測試實踐，根據功能和產品所處的生命週期，描述了這樣一些開發及測試實踐
測試左移
其中在開發新功能時候我們需要不斷的問自己，我們實現的功能是什麼？對需求做詳盡的分析。作者認為bdd是乙個很好的實踐，使用者或者客戶去描述產品的行為，這種描述是有一定的規則或語法的，可以直接作為測試用例的描述，通過這些描述實現自動化的測試用例，那麼我們的功能實現**只需要通過這些測試用例就可以滿足使用者的需求了。
這是測試左移的思想，本質是在一切開始之前先進行測試，測試物件是需求，越早的發現需求不合理的地方出問題的機率就越低。
另外測試左移還可以是在開發階段就進行測試，開發階段可能產出只是**，而不是完成的功能，這時候比較合適的測試是做持續整合的單元測試，通過**覆蓋率的方式找到未經測試的**，盡可能的保證**都被測試到。這些單元測試的用例可以在bdd時候通過使用者或客戶的用例描述來提煉。
總之左移是在測試階段到來之前，盡可能的抓緊開發前(需求分析)和開發中的時間做測試，提前發現問題，防微杜漸，避免積重難返。
測試右移
左移是往測試之前的開發階段移，右移是往發布之後移。也就是產品上線了之後也可以進行一些測試活動。當然在生產環境直接做測試是不推薦的，但是我們可以在生產環境做監控，監控線上效能和可用率，一旦線上發生任何問題，盡快反應，提前反應，給使用者良好的體驗。
測試右移其實還可以理解為如果線上發生任何問題，我們有沒有能力第一時間發現問題並解決問題，並保證線上資料的一致性或盡可能少的影響線上使用者。
很對時候，右移比左移更具有挑戰性。
我們可以做什麼
這裡y有一些測試實踐，是在不同的階段可以去做的
其實我們不妨眼光放的更長遠一點，軟體測試實際上是軟體質量控制，質量控制有很多實踐，一些實踐適合測試人員去做，另一些則可能不適合，比如線上效能監控，比如單元測試等。所以質量不只是測試團隊的事情，而是整個專案或者產品團隊需要重視的問題。一般來說，注重質量的團隊產品或者交付質量往往好於不太重視質量的團隊，或者把質量的指標壓在測試人員頭上的團隊。
質量無小事，質量也不是某幾個人的事。好的質量是團隊的榮耀，不好的質量也不應該是某幾個測試人員的鍋。
最後，從質量管理的角度上看，好的質量管理者可能需要具備下面的一些素質
測試左移和右移
大家熟悉的測試工作可能是，接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試 提bug 回歸，測試通過後就結束了，專案交給運維上線，之後投入下乙個專案繼續重複這樣的流程。這樣的流程看似沒什麼問題，但缺點是，測試同學非常被動 當需求質量 開發質量差的時候，你只能被...
關於「測試左移」 「測試右移」
作者新建了qq群 460430320，供大家交流測試心得 培訓機構勿進 另外，還會不定期上傳測試資料，也歡迎您共享測試資料。之前寫過該話題的部落格，但最近在看一些大佬聊天的時候，感覺get到了一些新的思路，拿過來，分享給大家。1 測試左移 右移，可以針對測試團隊來說，左移就是盡早的參與專案，從需求階...
測試左移與右移
大家熟悉的測試工作 也是傳統的瀑布式 是接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試 提bug 回歸，測試通過後就結束了，專案交給運維上線，之後投入下乙個專案繼續重複這樣的流程。這樣的流程看似沒什麼問題，但缺點是 測試左移以及測試右移，能夠讓測試擁有更多的...