相較於測試左移，測試右移雖然從定義上來看相當重要

但卻不一定是每個QA工程師都會碰到並負責的領域

原因很簡單，這跟產品的開發階段與成熟度有很大的關係。

如果你負責一個已經有客戶基礎的產品，那產品本身已經公開發行

可以從真實環境得到資料，充分利用這些資料回饋去改善產品的方方面面

但如果你負責的產品是個新創，開發時間長，產品還沒上到真實環境給客戶驗證過

很大部分QA能做的，容易會被限縮在產品發行前的驗證項目，而不容易實踐測試右移

以開發團隊的角度去看，其實只要產品上線，遇到的問題可以用很多切入點去解決

最大的問題可能就是產品遲遲不上線，沒辦法拿到客戶真實的回饋就無法持續改進。

呼應測試左移的Takeaways，針對測試右移我也提出幾個觀點來幫助思考：

風險評估與災難回復 (Risk assessment, Disaster Recovery)

以QA角度來說，產品沒辦法上線，可能的原因是產品品質還沒達到「特定程度」

這個特定程度很可能是一種抽象的感覺，QA可以做的就是把這個模糊程度具體化

而品質不夠這件事再往後看，白話一點來說其實可以看成：「怕上線後出大事」

怕出大事的原因其實只是沒有評估過風險，不知道「最糟的情況」會是什麼樣子

一但把所有可能的問題都列出來之後，就可以評估是否可以承擔這樣的風險

如果不行，就修到好，如果可以，就上真實環境做驗證。

可以承受的風險，會不會大幅度的影響既有的客戶？我們會用什麼方式去處理問題

如果出事了要怎麼回到正常狀態？要Rollback還是Fix-forward？有沒有備案？

未評估的風險其實跟定時炸彈差不多，未知就是一個人類本能上害怕的東西

而QA就只是把潘朵拉的盒子打開，拿起鉗子喀嚓一剪。（有點簡化了）

建立一個疏而不漏的軟體品質防護網

什麼叫做疏而不漏？就是看似鬆散卻不會讓Bug逃掉的品質防護網。

花很多時間編織很細但面積很小的漁網，就像所有時間都耗費在很小但測很深的功能上

身為QA，不如照顧到80%的測試情境，剩下的20%就靠風險評估去做有效的決策

這也呼應了「測得深不如測得廣」。

若是在有限時間內的測試，你的首選一定是確保大部分東西ok的回歸測試

回歸測試跑過了，重複跑，持續思考什麼才是最重要的事，

因為不重要的事做多了，也不會變得重要。

開放的心胸與勇於承擔失誤的態度

這點有些八股甚至雞湯，但我認為對想要實踐測試右移的團隊也十分重要。

如系列第一篇所提，測試右移的核心是想要在真實環境上驗證測試環境做不到的事。

包含產品可用性、穩定性、環境衝突與相容性、執行效能、用戶體驗等

某個程度上這是在說，QA團隊有些測試是無法在內部環境有好的測試效率

所以有些測試項目我們就直接在生產環境測試與驗證，並持續改進與加強測試。

也因為是在真實客戶環境上做驗證，百密總有一疏，難免還是會有疏漏

這個時候其實會需要團隊是比較能夠有容錯的心態，盡量對事而不要對人

透過像是寫RCA(Root Cause Analysis)要說明為什麼會有ooxx的問題

並一起找出測試與開發上環節可以改進或是未來納入開發測試設計考量的點。

至於測試右移的哀愁部分，我覺得是因為很多東西不是你可以控制的

客戶環境會發生什麼不知道，Remote debug解不掉要怎麼道歉，過年on-call被call怎辦

而測試右移的美麗就在於跟若有似無的風險共存，並用團隊的配套措施見招拆招

在一次次的快速失敗中汲取經驗，持續進化成比昨天更強大的QA扛霸子。

大概是這樣，有想到什麼再補充。

接下來就開始講一些跟測試右移有關的項目

先從風險管理(Risk Management)的基本概念與常用實例講起。