轉載：http://www.testclass.net/2017/12/11/shift-left-and-shift-right/#

前幾天看爬文的時候看到了這篇《Shift left and shift right: the testing Swing》，裡面描述了一些測試左移和測試右移的思路和方法，覺得有一定的啟發，可以分享一下。

作者站在專案或者產研發負責人的角度闡述了自己團隊在敏捷及devops中的測試實踐，根據功能和產品所處的生命週期，描述了這樣一些開發及測試實踐

• 開發階段

  • 新功能： 我們應該做什麼？
  • 已有功能：如何自動化？

• 產品階段

  • 新功能：如何驗證新功能所帶來的使用者價值
  • 已有功能：效能及可用性監控

測試左移

其中在開發新功能時候我們需要不斷的問自己，我們實現的功能是什麼？對需求做詳盡的分析。作者認為bdd是一個很好的實踐，使用者或者客戶去描述產品的行為，這種描述是有一定的規則或語法的，可以直接作為測試用例的描述，通過這些描述實現自動化的測試用例，那麼我們的功能實現程式碼只需要通過這些測試用例就可以滿足使用者的需求了。

這是測試左移的思想，本質是在一切開始之前先進行測試，測試物件是需求，越早的發現需求不合理的地方出問題的機率就越低。

另外測試左移還可以是在開發階段就進行測試，開發階段可能產出只是程式碼，而不是完成的功能，這時候比較合適的測試是做持續整合的單元測試，通過程式碼覆蓋率的方式找到未經測試的程式碼，儘可能的保證程式碼都被測試到。這些單元測試的用例可以在bdd時候通過使用者或客戶的用例描述來提煉。

總之左移是在測試階段到來之前，儘可能的抓緊開發前(需求分析)和開發中的時間做測試，提前發現問題，防微杜漸，避免積重難返。

測試右移

左移是往測試之前的開發階段移，右移是往釋出之後移。也就是產品上線了之後也可以進行一些測試活動。當然在生產環境直接做測試是不推薦的，但是我們可以在生產環境做監控，監控線上效能和可用率，一旦線上發生任何問題，儘快反應，提前反應，給使用者良好的體驗。

測試右移其實還可以理解為如果線上發生任何問題，我們有沒有能力第一時間發現問題並解決問題，並保證線上資料的一致性或儘可能少的影響線上使用者。

很對時候，右移比左移更具有挑戰性。

我們可以做什麼

這裡y有一些測試實踐，是在不同的階段可以去做的

• 開發階段

  • 新功能： 單元測試, BDD, 探索性測試
  • 已有功能：自動化驗證，效能測試，

• 產品階段

  • 新功能：可用性測試
  • 已有功能：實時效能監控及使用者反饋收集

其實我們不妨眼光放的更長遠一點，軟體測試實際上是軟體質量控制，質量控制有很多實踐，一些實踐適合測試人員去做，另一些則可能不適合，比如線上效能監控，比如單元測試等。所以質量不只是測試團隊的事情，而是整個專案或者產品團隊需要重視的問題。一般來說，注重質量的團隊產品或者交付質量往往好於不太重視質量的團隊，或者把質量的指標壓在測試人員頭上的團隊。

質量無小事，質量也不是某幾個人的事。好的質量是團隊的榮耀，不好的質量也不應該是某幾個測試人員的鍋。

最後，從質量管理的角度上看，好的質量管理者可能需要具備下面的一些素質

• 把質量問題上升為整個研發團隊或產品團隊責任的能力
• 能推動各種角色進行高效合理的測試實踐的能力