前幾篇把測試右移的一些關於資料收集處理呈現的實踐，大致上講得差不多了，

這篇來補充說明前面沒特別提到，但我覺得對QA是個蠻重要的武器

就是大家耳熟能詳的數據驅動(Data-Driven)

除了有利說明自己在測試工作上的規劃外，也是平日在溝通上很好用的能力。

數據驅動的目的

我覺得用簡單的講法來說就是：「建立信任。」

其實規劃本身就是「主觀」的東西，也很依賴QA的判斷能力以及經驗來看要測或不測。

而在審查會議這類像是取得共識的會議中，你會需要有個比較客觀且明確的資料

來去說明與說服大家說，你的測試計畫跟優先度的順序不是瞎扯一通，而是有憑有據。

用一個QA最常會被問的實際問題，來說明Data-driven我覺得是最直覺的。

在測試計畫審查會議(Test plan review)的時候，當你被問：

「為什麼你的回歸測試會選這些OS來測？」

「為什麼你的功能測試不需要測試到B功能相關？」

如果在說明自己的測試項目的規劃時，有「客觀」的資料來作佐證說明的時候

那個說服的力道就完全不一樣。舉個簡單的例子回答上面的兩個問題：

「因為我們從後端收集回來的遙測資料看到，客戶的環境組成主要以70%的Win10，其中又都以最新版本為主，再來是25%的Win7，跟10%左右的Win Server 2022，所以這次新版上線的回歸測試優先度會以最新版的Win10為最優先，加上Win7與Server 2022也會驗完，這樣95%的平台都能被cover，其他平台如果有時間，會再排一兩個測試。」

「因為看過修改的程式碼後，以及跟RD討論過後認為這次修改不會影響到B功能，而且從功能使用的客戶資料來看，使用B功能的人大概不到5個客戶，如果真的有問題，我們也有後台機制來關閉功能，對客戶不會造成任何影響。」

當你的測試計畫是藉由真實客戶資料去安排調整，整體說服力就高了不少。

又加上如果有像是軟體上的部署機制(Deployment)做回滾(Rollback)的修正

即使出了問題，都有辦法可以把修改錯誤的地方復原成原來的樣子

那對於軟體品質上面的提升，也能夠起到很好的作用

最重要的是，你的判斷是有個客觀數據去做論點上的支撐

不是因為Win8.1很難用，不想用那個環境測試，而是用8.1的客戶真的很少！

也不是因為網頁登入這段不測，是因為這次我們修的是寄通知信的Bug！

數據的意義

最後針對資料收集再做一點補充。

從測試右移提到遙測資料，又用客觀資料來優化主觀的測試計畫。其實有個重點是，

「在一開始決定要收什麼資料的時候，就要明確知道資料所代表的意義。」

包含它會怎麼被使用，做成什麼樣的儀表板圖，緊急程度需不需要加入警示系統

如果出了問題，維運團隊要怎麼去反應跟做事，後續的follow-ups都要討論清楚。

不然就會變成一種很尷尬的狀態是：哦，我們想要收這個資料，感覺之後會有用

然後收了之後沒人做資料處理跟實際應用，變成為了收資料而收資料，就會有點可惜。

下篇來講上面有提到關於軟體部署(Deployment)的一些有名且實用的策略

以及QA可以怎麼藉由這些策略幫助測試右移的實踐。