測試左移和測試右移


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

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

  • 開發階段
  • 新功能: 我們應該做什么?
  • 已有功能:如何自動化?

  • 產品階段
  • 新功能:如何驗證新功能所帶來的用戶價值
  • 已有功能:性能及可用性監控

測試左移

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

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

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

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

測試右移

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

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

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

我們可以做什么

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

  • 開發階段
  • 新功能: 單元測試, BDD, 探索性測試
  • 已有功能:自動化驗證,性能測試,

  • 產品階段
  • 新功能:可用性測試
  • 已有功能:實時性能監控及用戶反饋收集

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

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

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

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

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com