對測試工作常會有種印象是：「要在產品上線前，完成所有的測試項目。」

這點從邏輯上來看是沒錯，但在實際執行測試卻是一個相對理想的狀態

比如在上篇提到的相容性測試與可用性問題，就較難在內部環境測試出來。

那這類問題通常是要怎麼去發現呢？

這篇來聊聊測試左移與測試右移的基本概念。

測試左移(Testing Shift-Left)

測試左移，以軟體開發的時間軸來看，把產品發行的時間點當作里程碑

在產品上線發布前，盡早開始測試計畫與項目，力拼在左側完成測試。

像是測試驅動開發(TDD)或是行為驅動開發(BDD)都是測試左移的概念應用

目的也是確保能做對的事(Do the right things)，並跟產品的業務目標緊密配合。

這也是為什麼敏捷開發與DevOps這麼推崇測試左移的概念

藉由持續收集反饋與改進驗證，來確保產品是否符合預期。

測試左移示意圖

一般的開發與測試時間軸，搭配Bug的引入與發現時間，以及Bug修復成本。

藍色的線代表產品缺陷的引入，大部分都在開發階段發生

橘色的線代表Bug的發現時間與數量關係，測試越全面越能找到整合型的複雜Bug

紅色的線代表Bug修復成本，如果是設計類型的Bug，後期可能就要花很多時間改。

而上圖到下圖就是一個測試左移的示意圖，

常見的實踐包含QA在RD開發階段就參與設計討論，在極早期發現潛在問題並提早解決。

測試右移(Testing Shift-Right)

測試右移相對於左移而言，是在產品上線發布後，去驗證現實世界會遇到的事情

舉凡前面提到的相容性、環境衝突、執行效能、用戶體驗等等問題

也會更關注產品整體的可用性、穩定性、遙測資料分析等等更多有助提升品質的面向。

測試右移更多包含客戶持續反饋與開發團隊持續開發的過程

但我覺得對開發團隊來說，最有價值的部分包含兩個：

• 能知道實際生產環境(Production)的負載量
• 能夠得到測試環境無法做出來的真實環境複雜度

第一項是對開發團隊的優點，產品上線之後會清楚知道各伺服器負載的實際狀況

開發測試的時候，我們會對不同的模組功能有既定的功能切分，來分配server資源

但如果實際客戶是用A功能去做B應用，很可能會產生不如預期的錯誤。

第二項是對測試團隊的優點，我們可以從遙測資料來監控使用者如何使用產品

並從資料分析中更有效的了解，產品執行的環境與可能遇到的各種潛在問題

更進一步，了解實際產品環境後，還能夠建立更多樣的測試環境以貼近生產環境

這些都有助於後續測試計畫的設計與回歸測試的重點優先項目。

大致了解左移與右移的概念之後

下一篇就來聊實戰應用與QA工程師可能遇到的問題。