在產品開發過程中，軟體測試是其中一個要處理的事情。大家對它的態度很有趣：
- 在大家或是客戶面前，總是信誓旦旦地說，它是一件非常重要的事。
- 私下在趕專案的時候，總是想把它第一個放棄，或者是簡單做。
- 真的要去做它的時候，覺得並不是很懂它，不太知道要怎樣做會比較好。
這樣的現象，在軟體圈變成是沒有公開的共識，今天我們就花點時間來談談這個秘密，因為這樣的思維，導致軟體測試變得很難。
1.1 測試思維矛盾
在自己開始當顧問後，接觸到許多客戶或是朋友，他們會提到公司的狀況，或者是提到他們測試的狀況，發現到很多很神奇的鬼故事。例如：
- RD常用“寫測試“這個說法，因為很多人認為測試就是自動化測試。手動測試不用寫，內心預設不把當作是測試的一部分。也就是說他們的測試只是單元測試或是端到端測試，其他類型的測試就不會做，或者是不該屬於他們要做的。
- RD很愛學習或是了解測試自動化的作法，但是回去後還是沒有寫測試自動化。原因可能很多，不外乎時間不夠，或是舊系統(Legacy System)不易轉撰寫測試自動化。另外，很多RD認為只有寫程式是技術，測試相關的知識不是技術。
- RD或是管理者常常提問，有沒有好用的測試自動化工具。每次在研討會、測試課程、或私底下的諮詢，都會重複聽到這樣的問題。可是回去之後，真的會去買哪些工具的不多。就算有買，也會聽到不會用、不好用、和沒空用，最終還是沒去做測試自動化。
- 管理者跟大家講測試很重要，可是就是嘴上說要，身體卻很誠實。很少對測試安排足夠的時間，也不投資在測試上面的培訓。如果你測試找到很多問題，可能還被嫌棄，認為給大家找麻煩。
- 管理者常常抱怨測試資源不夠，但是可以補缺額時，通常測試人員不會是首選。如果真的會補來做測試，往往他們會補測試開發工程師，也就是來做測試自動化的RD。沒錯，這就是RD，只是他們的工作，把已知的檢查步驟給自動化。這是在寫程式，不是在做測試。所以一樣抓不到 Bug，只是之前沒有測試自動化，現在有了。
- 管理者覺得RD有做測試自動化，就代表程式品質沒問題。因為他們對測試不懂，以爲自動化後就可以抓到所有問題，並且之後測試執行就會很快，並且這些測試程式也不用維護，放下去跑就自動做事了。
- RD在開立測試個案時，通常個數都不多，很多團隊大多不會超過10個。他們嘴上會說這樣的測試個案夠了，不太可能有人這樣用。可是私底下問他們，卻擔心測不完整，深怕發佈之後會出問題。
這樣的故事一直在進行中 ……
聽到上面的故事，你是不是覺得很熟悉呢？這樣很矛盾的狀況，一直持續在發生。一方面是沒有相關知識，不知道這樣想是錯的；或是明明該做什麼，可是卻不做。
1.2 測試成本太高想賭不會這麼倒霉
雖然測試聽起來不難，但事實上，測試的成本比你想像的高，讓我們來看看一些統計數據：
- 軟體測試活動花費大約佔全部的15%-25%
根據2019年對IT人員和CIO的一份調查報告[1]可知，軟體測試活動大約佔專案費用的15%-25%。
| 年份 | 測試花費比例 |
| 2012 | 18% |
| 2013 | 23% |
| 2014 | 26% |
| 2015 | 35% |
| 2016 | 31% |
| 2017 | 26% |
| 2018 | 26% |
| 2019 | 23% |
- 測試人員成本
網路上軟體測試人員成本的不多，很多內容雷同，這裡找到一篇[2]有比較清楚一點的介紹，根據地點、測試作法和角色，測試人員的成本如下：
- 根據地點的調查
| 美國 | 每小時美金 35-45 元 |
| 英國 | 每小時美金 20-30 元 |
| 印度 | 每小時美金 10-15 元 |
| 越南 | 每小時美金 8-15 元 |
- 根據測試作法的調查
| 功能測試 | 每小時美金 15-30 元 |
| 自動化測試 | 每小時美金 20-35 元 |
| 效能測試 | 每小時美金 20-35 元 |
| 安全測試 | 每小時美金 25-45 元 |
- 根據角色的調查
| Quality assurance engineer | 每小時美金 25-30 元 |
| Test Engineer | 每小時美金 25-30 元 |
| Senior quality assurance engineer | 每小時美金 40-45 元 |
| Automation test engineer | 每小時美金 30-35 元 |
如果以一個月174小時來計算，美國測試人員月薪就新台幣182,700元(35美金x 174小時x 30台幣美匯率)起跳。這個成本真的是不低。
因為軟體測試人員的薪水不低，再加上要買工具和平台，那個成本對很多公司來說算是不小的負擔。因此，有些公司只好另闢蹊徑，少做點測試，簡單說就是在賭。賭倒霉的事情不會發生，客戶不會做傻事，不會輸入這樣神奇的數字，駭客不會看上我們。那這樣做可能會付出什麼代價呢？讓我們從數字角度來看看：
- 2024 年7月資安公司CrowdStrike，它的軟體Falcon Sensor造成微軟 Windows作業系統當機，螢幕呈現藍色畫面，導致全球機場服務當機，很多交通，旅遊業受到嚴重影響。CrowdStrike市值損失3800億。
- 2023年國內某證券的App，在7月兩度當機惹議，導致金管會宣布對這綜合證券處以新台幣150萬元罰鍰，期貨罰60萬元，合計共裁罰210萬元[3]。
- 2022年國內某銀行系統一再當機遭罰1200萬、總座降3成薪[4]。
- 2021年Line Pay全球大出包，逾7萬台灣用戶個資受影響[5]。
- 2021年Line系統當機，50分鐘後需重啟才能傳遞訊息[6]。
由上面的調查資料知道，軟體測試成本不低，如果要做好做滿，是需要不少銀子。但是如果選擇偷雞，沒事可能賺到，不過只要出事一次，那個代價往往無法承受。所以軟體測試做與不做真的蠻兩難的。
1.3 台灣軟體測試的現狀
這裡讓我們換個角度來，台灣軟體測試目前現狀如何，在各個面向上，軟體測試的活動、教育和支持上，是否很到位。
- 相關參考資料少
市面上有關於軟體測試的書籍或文章很少，即使有也多數偏向是自動化測試。測試基本知識幾乎沒有，更不用說業界經驗分享。若不是成大李信杰之前邀請大家共襄盛舉，分享的業界目前測試經驗，否則還真的幾乎是翻譯書籍。
以下是國內自己同胞撰寫的測試相關書籍，第二本和第三本便是和測試自動化相關的書籍：
- 軟體測試實務 : 業界成功案例與高效實踐(1)(2)，2023
- 你就是不寫測試才會沒時間：Kuma 的單元測試實戰 — Java篇，許煜松(Kuma)，2022
- 前端測試指南：策略與實踐，唐心皓(Summer)，2024
其他大多是國外翻譯書籍，或者是對岸所撰寫和翻譯的書籍。目前從天龍網路架上來看，國內作者的書籍在最近5年內就是哪3本。
- 社群不活躍
在社群方面，目前我在Facebook和Line上所能查到的，是屬於中文和國內建立的，大約是以下幾個：
| 社群渠道 | 社群 |
| Test Corner Agile Testing in Taiwan 中華民國資訊軟體品質協會CSQA | |
| Line | QA工程師/測試工程師/軟體自動化社群 QA/測試職缺資訊分享區 |
- 學校開課少
台灣在2024年時，大專院校數有155所，其中公立49所，私立106所。目前在網路上我能查到的課程一共9門，公立學校開設4門，私立學校開設5門。這些課程有些開設年代有點遠，有些可能只開過幾次，並非是常態性課程。
- 軟體測試Software Testing，陽明交通大學
- 軟體測試Software Testing，台灣大學
- 軟體測試分析與品保，成功大學
- 軟體自動化測試專論，成功大學
- 軟體測試與維護，德明財經科技大學
- 軟體測試，中國科技大學資訊工程系
- 軟體測試與驗證，東海大學
- 軟體測試，逢甲大學
- 軟體測什麼：工程師的實戰心法，中華開放教育平台
如果學校不太有人會開這些課程，上班以後公司也不太重視，所以幾乎沒人懂軟體測試也是十分正常的事情。
- 2021 國內軟體測試調查
在 2021 年時，我做了一個問卷，在Facebook社群上面調查軟體測試的狀況，大約有 120人左右，應該還是有些參考價值。
- 公司內有多少測試人員
有90%的公司，測試人員不到50人。其中大約60%，不到10個人。
| 專案狀況 | 比例 |
| <10人 | 61.7% |
| 10 – 50人 | 28.3% |
| 50 – 100人 | 2.5% |
| >100人 | 7.5% |
- 公司內測試人員與開發人員的比例
大約50%的公司，開發人員是測試人員的5倍(含5倍)以上。
| 專案狀況 | 比例 |
| 1:1 | 2.5% |
| 1:2 | 10.8% |
| 1:3 | 13.3% |
| 1:4 | 15.8% |
| 1:5 | 8.3% |
| 1:5 以上 | 36.7% |
| 沒有測試人員 | 8.3% |
- 產品測試時間的長短
測試時間在1周內佔 55%，在2周內佔約75%
| 專案狀況 | 比例 |
| < 3天 | 18.3% |
| 3天 – 1週 | 36.7% |
| 1週 – 2週 | 20.8% |
| 2週 – 3週 | 5.8% |
| 3週 – 4週 | 8.3% |
| 1個月 – 2個月 | 1.7% |
| 2個月 – 3個月 | 1.7% |
| 3個月以上 | 6.7% |
- 平均一個專案的 測試個案 規模
測試個案個數小於 100 個佔70%
| 專案狀況 | 比例 |
| < 10個 | 15.8% |
| 10 – 30 個 | 19.2% |
| 30 – 50 個 | 19.2% |
| 50 – 100 個 | 15% |
| 100 – 300 個 | 11.7% |
| 300 – 500 個 | 4.2% |
| 500 – 1000 個 | 5% |
| >1000個 | 10% |
- 目前專案中自動化測試個案佔全部測試個案的比例
大約63%的專案，他們自動化測試個案不到10%
| 專案狀況 | 比例 |
| 沒有自動化 | 31.7% |
| 1% – 10% | 31.7% |
| 11% – 30% | 14.2% |
| 31% – 50% | 8.3% |
| 51% – 70% | 3.3% |
| >70% | 10.8% |
由上述的資料可以知道，在台灣的公司中，測試人員的數量真的不多。每次進行測試，給團隊的測試時間也不長，1-2周是最常見的狀況。有可能這個時間還包含修復和驗證Bug的時間，所以實際測試的時間可能更短。
測試個案的數量不多，可能來不及開立，或是開不太出太多測試個案。所以團隊會擔心測試不完整，這樣的狀況應該也是很正常。沒有測試自動化的團隊大約佔3成，即使有做自動化，自動化的比例也不高，4成5的團隊不高於30%。看起來絕大部分的都是手動進行。
1.4 軟體測試的挑戰
即使沒有前面的那些狀況，公司願意好好處理軟體測試，我們在進行測試的過程依然不是那麼容易，有不少挑戰我們需要面對。我們將列出在測試方面，會遭遇哪些難題，讓你在進行之前，可以先思考這些要如何處理或是減緩。以下是常見的十個軟體測試挑戰。
| 溝通是傳話遊戲 缺乏資源 變化很多很快 時間有限 缺少文件 測試不充分 測試環境不穩定 相容性的組合太多 測試數據很難準備 好的測試人員不好找 |
- 溝通是傳話遊戲
測試基本上要確認客戶的需求是否被正確的實踐。一開始是客戶描述給PM，PM再說給SA，SA再跟開發人員解釋，最後開發再跟測試說明。中間這一連串的傳話，很容易就會失真。
我想很多人玩過傳話遊戲，或是看過電視上的演出，就會像下圖1-1所示，第一個人說我要4隻豬，到最後可能變成我要吃豬腳。傳統開發過程中的作法，很容易就會產生這樣的結果。
如果想要避免誤傳，建議很多過程需要多角色一起討論和交流，確保對訊息的了解是一致的。例如：敏捷開發中的實例化需求，或者是測試左移的作法，都是減緩傳話遊戲所帶來的問題。有些人或許會說，這樣的討論很花時間。我想花時間能有共識，應該比不花時間卻做出錯的東西好多。
圖 1-1 測試很容易變成傳話遊戲
- 缺乏資源
軟體開發的資源一向都很緊張，光是開發人員都不太夠用，更不用說會有專職測試人員來幫忙，往往都是開發人員要來做測試。所以這時候不應該考慮角色別，而是有這麼多事情，需要大家一起分工完成。
此外，不只人員短缺，在進行測試時，所需要的測試軟體或是硬體，往往也是不夠。像是APP測試時，本來需要多種機型或是作業系統，往往都只有基本款的手機可用。對於複雜的雲端環境或是網路裝置，大多也只有Production一套，Stage環境可能就退化成陽春版，或者甚至沒有。
- 變化很多很快
眾所皆知，在開發過程中，客戶常常會修改需求。或者客戶發現他自己想錯了，需要做出調整。老闆也常常忽然臨機一動，不斷地落下隕石。在這樣的狀況，開發人員的時間不多，測試的人員的時間更不多。
另外，除了外面需求外，還包括開發人員自己也會作怪，有時候可能會進行重構，也可能是自己發現了一些問題，是測試人員沒發現的，所以自己便動手修改。這麼多修改，常常是偷偷出現，檯面上沒有指派的工作，測試人員都要自己吃下去。
圖 1-2 隕石太多導致測試很難兼顧
- 時間有限
如下圖1-3所示，在產品開發時，常見有兩種狀況。狀況一：分析設計花了一些時間，但最大宗可能在撰寫程式的時間，前面可能花掉80%或90%的時間，或者更多，最後剩下的時間才來進行測試。
狀況二：PM或是老闆們討論需求花了大把時間，可能1/3以上的時間再思考方向，或者猶豫不決等到進到開發團隊時剩下時間不多，寫程式還是需要花點時間，因此等到測試人員拿到時，那個時間的量只是個渣渣，就只是形式有做測試，但是沒有什麼實際用途。
另外，最怕的是最後一刻的修改，這時候往往幾乎沒有充分時間進行回歸測試，並且對於修改的東西掌握度也不高，因此，測試的進行是難上加難。
圖 1-3在規劃時程時測試並沒有被充分考量到
- 缺少文件
如下圖1-4所示，在開發過程，通常需求文件都是比較簡單的描述，但也可能接近於零。至於開發的設計文件，往往是沒有的，就算要有也是整個開發完畢之後，開發人員才會有空去寫。
在這樣的狀況下，測試人員可能是靠口耳相傳，或者是自己很神奇的通靈術，想盡各種方法去了解受測軟體，因此這樣要能測好，真的是件不容易的事情。這是常態，不是變態。
圖 1-4 中間這些文件往往是沒有
- 測試不充分
目前大家在進行測試時，多數測試人員都是在做功能測試，而開發人員就是寫寫單元測試，勤勞一點的就再多點E2E(端到端)測試。其他種類的測試就沒有進行。由下圖1-5所示可以知道，我們還有安全性測試、可變比例性測試、效率測試和易用性測試等等，一堆不同測試活動要做。
有時候沒有做其他的類型的測試，前面說到的時間不夠，是最主要的原因。另一個可能的原因，便是不懂，沒有相關的測試知識和技能。例如安全測試，或許大家知道要用什麼程式碼掃描的工具，但是在掃出來後，對於問題的解讀和解決，沒有安全相關知識，要能解掉也是很難的事。
圖 1-5 往往以為做了功能測試就是做完全部測試
- 測試環境不穩定
為了要有準確的測試結果，我們需要準備獨立的測試環境，來確保不受到環境因素所影響。也就是不要有在我這邊可以，在你那邊不行的狀況。
但是為了要進行測試，受測軟體需要常常更新，只要開發人員有修復。另外，因為受測系統的異常狀況，導致測試環境也可能常常受到破壞。這些都需要測試人員不斷去維持一個正常且乾淨的環境，這個成本其實是不小的。
- 相容性的組合太多
受測系統所在的環境通常不少，可以是存在的作業系統，所支援的瀏覽器，或是可以連接的資料庫。如下圖1-6所示，這些組合可能可以數十個到數百個。再加上如果測試個案的數目有數百個到數千個，這樣乘出來的數目就非常驚人。測試人員可能可以跑完一次，但是如果需要多次回歸測試，那是不可能的任務。這些組合沒有去測，我們也不好意思宣稱我們支援這麼多環境，這樣是無法對得起客戶的。
圖 1-6 組合太多導致測試很難
- 測試數據很難準備
測試要測得好，找對測試資料很重要。同樣的場景，輸入(0,-1)和輸入(2,3)，前者可能會找到問題的機率比較大。
因此，你要測試時，測試資料不能夠只是單一狀況，尤其都是理想場景(happy path)的狀況，需要有不正確的資料。除了不正確外，還需要像真實狀況，不像真的會發生的場景，那測試了也是白測。
另外，資料的產生最好也要能自動化，可以快速產生，這樣測試才能比較方便進行。有時候為了像真的，可能需要引用真實資料，但是要去識別化，避免從這些資料可以猜出真實用戶在做什麼事情。這些都是不容易做到。
- 好的測試人員不好找
在台灣測試人員不好找，因為能力強，又會寫程式，大多會跑去當開發人員。不會寫程式的，如果腦筋不夠多元，不會想到一些不同的狀況，測試也會做不好。
就算有合適的人選，也常常無法給出好的薪水，因此人才常常會跑去國外，或者是外商或待遇不錯的中小型公司，傳產或是薪水不高的公司，很難選到好人才。
此外，就算進來之後，主管或者開發人員常常不太尊重他們，總認為他們的工作很簡單，誰來做都可以，沒有技術成分，沒有太多價值。更不用說要對他們進行培育，多數的測試人員只能私下自己默默去學習。所以基於上述原因，願意當測試人員的真的少之又少。
參考資料
[1] Proportion of budget allocated to quality assurance and testing as a percentage of IT spend from 2012 to 2019
https://www.statista.com/statistics/500641/worldwide-qa-budget-allocation-as-percent-it-spend
[2] How Much Does Software Testing Cost and How to Optimize It?
[3] 國泰證樹精靈App兩度當機，卡65分鐘股民焦慮…金管會開罰210萬：舉證損失公司須負責
https://www.businesstoday.com.tw/article/category/183017/post/202309010030
[4] 史上最重！國泰世華銀一再當機，遭罰1200萬、總座降3成薪！
https://www.bnext.com.tw/article/73497/cathaybk-fine
[5] Line Pay全球大出包！逾7萬台灣用戶個資受影響 公司滅火說話了https://www.wealth.com.tw/articles/dfcb9ce9-b1a3-4c9f-a0d3-78be9021e93b
[6] LINE連線異常當機50分鐘 恢復後訊息須重傳
發表迴響