這篇很長，沒看完或沒讀透很容易斷章取義或扭曲原意，慎讀

ChatGPT除了帶來新的技術革命，好像也帶來了不少焦慮感，前一陣子我們才談了由學員提出的「你可以不必是大神」，而現在ChatGPT的興起，也造成了一些學員對未來的困惑。

這次的文章乾貨很多，邏輯很多，請一定要仔細看，跟好囉，看完後，應該可以更多的解除你的焦慮感，不要分享出去，太多人知道，可能過陣子會被刪掉，建議自己收藏起來，但是按讚還是可以的。

你假如害怕被取代，一定要先解決這三個問題，尤其是最後一個，會改變你的人生

(這段話…怎麼有種網路影片的既視感)

還記得QAQ什麼第一篇部落格的主題，曾經想要討論過「軟體測試的本質」，但當時我還沒想得很透，過了近一年，為了回答這個問題，我想先給出一個階段性的答案

「避免風險」

沒錯，軟體測試的本質就是避免風險，當我們選擇不做測試的時候，最根本的原因跟想法，就是選擇了「接受風險」

• 測試測不完？沒辦法，專案時間是訂死的，直接發版吧
• 回歸測試有五百條要測？這樣測不完，不然測到哪算到哪吧
• 測試要補人？先不用吧，先加在開發

相信先拋出這三個，大家能想到千千萬萬個同樣是被迫選擇接受風險的場景。

在「避免風險」的基石下，我們Bug來簡化問題，我們要怎麼讓產品沒有Bug?

通常會有兩個出發點:

1. 減少Bug的產生

2. 發現Bug的方法

但在這兩個問題點之前，又有一個問題要被解決，到底什麼叫Bug? 這個問題比我碩博在研究的認識論Epistemology還要難解決，都是種哲學問題。

前陣子才有篇新聞，說ChatGPT被發現Bug，因為沒有辦法限制在十個字以內回答問題，結果後續就很多人回覆條件要下對，或是模型是要訓練等等解法。所以往往Bug的來源是源自於用戶，而企業創造產品是為了滿足用戶，只要某種層面上無法獲得用戶買單，就會被視為Bug，因為人們很容易從自己身上找問題，卻忘記了用戶是沒有共性的，每個都是獨立的個體。

• 為什麼用戶都跑去競爭對手那了，應該是Bug造成我們的速度跟穩定性不好
• 為什麼很多用戶都說我們產品很慢或很卡? 用戶網路慢? 但別家的都不會啊
• 如果沒辦法打破長城，我們就沒辦法獲取大陸用戶，這是個嚴重的Bug

既然Bug的定義無解，那就回到前面的兩個出發點來討論

減少Bug的產生

這裡指的是從開發人員的角色出發，如何在撰寫程式碼時避免Bug的產生，目前比較有名的就是單元測試, Pair Programing, Code review, 程式碼靜態掃描，這題我就不班門弄斧了，接著講下一個

發現Bug的方法

這裡是指從測試人員的角色出發，如何在發版前及早的發現Bug，目前比較有名的就測試左移、自動化回歸、用人力碾壓測試Daily build(???)

這裡不談論哪種方法好，我們就從這些方法作為起點，來談論本次部落格題目提到的三個問題。

第一個，公司對測試的投資比例

可以先從人力、時間、金錢三個角度來評估一下自己的公司在測試上的投資比例是否和其他團隊比起來很懸殊

• 人力: 開發人員與測試人員的比例?
• 時間: 一個發版週期裡，測試能用多少時間?
• 金錢: 從人力推算人事成本，再從採購的軟硬體去計算。

這三個都能個別寫好幾篇文章了，之後再來探討，相信算出來後，你能夠體會到我接下來要講的是什麼。

「只要有需要投資的地方，往往不會是測試」

這個狀況很現實，畢竟沒有產品就沒有企業，即使產品存在問題，也還是會有人買單，就像蝦皮早期很多Bug已經不是秘密，我遇到太多次結不了帳的狀況，但是仍然是發展到很大的規模。因為大多時候產品不是程式碼，而是整個商業模式，這些Bug只是一小部分的問題而已，很多時候是可以用其他手段來解決，像是提前揭露Bug或維修時間，用戶就能接受並等待。

當公司有滿滿的資金，為了生存和競爭，會最優先選擇投入產品研發，而不是讓產品趨近完美，即使是，那也是透過下一個產品來達到完美。

第二個，測試的遞迴性

即便公司願意把AI投資在測試上，仍然會產生第二個問題，測試的遞迴性。這個問題鮮少被提起過，但其實他正在發生，那就是自動化測試。

不知道有沒有人思考過，自動化測試是透過工具、框架、程式碼所累積出來的，那究竟有沒有誰來測試過這些由自動化測試工程師開發出來的自動化測試呢？如果是又透過某一套工具來檢測，那又誰來檢測那套工具呢？如果是ChatGPT，那又誰來檢測ChatGPT是對的呢？這種遞迴性，就像SRE追求99.99999%的可用性，每要多一個9，都是更大量級的支出，又會把問題拋回第一個投資問題了。

第三個，可測性

讓我們再度接受第二個問題，也就是測試的遞迴性是能被解決的，那第三個問題就顯得更不可能解決，也就是可測性。

用戶體驗完全相同的多個App，背後所使用的技術是完全不同的。所需觀察的測試點也就不同。以訊息同步來說，就有多種不同的技術，Polling, Long-Polling, Websocket等等，測試方式與條件也都會不同，測試人員在技術層面可能接觸比較淺，但廣度卻要相對更多。這也就衍伸出一種說法，「測試人員要比PM和RD更了解產品」，

在無法解決可測性的狀況下，「人」仍然得做最後一關的把控。就像自動化工廠一樣，其實目的是做到的是減少人為介入，是為了規格化和統一化，而不完全是消除人工。

這三個問題其實是一個循環

自動化或AI會有程度的消減人力，但是每次消減的程度要越多的時候，所要投入的成本就越高，所面對的問題就更複雜更關鍵，如果沒有足夠長的邊際效益，就會中斷投資，而停在了一個要上不上，要下不下的階段。

因此我一直以來推廣的測試概念，是維持人工介入的半自動化而不是追求全自動化。

有人曾經反駁我說：「意思就是最後還是要人測，難道人就不會出錯嗎？」

這時就要反問：「你的產品用戶是人還是機器呢？」

即使真的很多工作都被機器人取代了，巧克力冒險工廠早就教過我們了，即使鎖牙膏蓋的工作被機器人取代，只要願意，我們還是能夠變成修機器人的工程師，而且難道機器人壞了好幾天，該做的事情就不用做了嗎？

別忘了一個真理「每一個Bug都是創造就業機會」

與其擔心未來十年AI會不會取代軟體測試工程師，不如先想想到底我們還需要幾年的時間，自動化測試工程師才能做到100%都在做自動化吧