測試工程師，台灣也常稱 QA工程師 (Quality Assurance Engineer)，主要的工作目標是確保軟體產品的品質。
實際上 QA 工程師的工作範圍以及究竟要做到什麼程度 取決於公司跟團隊，業務範圍可大可小；從單純做測試開 Bug 到產品規劃、負責發正式版本、寫代碼等等都有可能。
不少人可能對測試工程師的業務內容感到好奇，不管你是正在考慮成為一名測試工程師或者已經是其中一員；在這裡我將以一名有八年測試經驗的過來人角度，總結出這個崗位的幾個特色，提供我的觀點給你，作為測試工程師入門的參考。
1. 測試工程師的入行門檻？
手動測試工程師 的入行門檻相較於開發、產品來說普遍比較低。
如果你是一個非資工學群相關科系出身的人，想要進入軟體業並能碰到一些技術面；甚至慢慢 自我學習、轉向開發 ，那測試工程師的個職位就很適合作為一個切入點。
（但是需要非常自律，並且時刻提醒自己目標在哪裡）
手動測試工程師這個職位時常願意招收沒有經驗的人，因為在測試領域中絕大部分新功能的 Bug 都是可以在用戶端體現出來的。
也就是說你只要會用手機電腦、作為一個早期用戶能夠發現問題，基本上就已經具備了最基礎的測試能力。
2. 測試工程師的交付壓力？
由於工作性質的原因，相較於開發需要在排定的時間段內生出對應的功能代碼、測試則 沒有那麼大的交付壓力。
即使公司可能會要求你事先準備好測試用例，但對於產品本身來說，測試用例其實並不是必要的：
- 假設測試沒寫用例，但是開發很強、或是剛好本次 Bug 很少，這種情況下不需要測試用例，直接進入測試階段也不會造成品質降低。（
總不可能把沒 Bug 測成有 Bug 吧） - 但反過來要是開發把代碼寫得漏洞百出，那肯定在測試這一關就會被發現了，無法糊弄過去，只能來回修改了。
再者 測試用例在實務上有很大的操作空間，一樣的功能用例可以寫的粗略、也可以精細。
甚至某些團隊在來不及測試的時刻，可能會放棄撰寫測試用例，直接改為「探索性測試」，因此 測試用例實際上不算是一種硬性的進度壓力。
另一方面，相較於開發寫代碼需要 debug 或者是各種卡關，測試用例是以我們都很熟悉的自然語言(人話) 寫成，再不濟也就是寫的比較差；或是思考不周、覆蓋率不夠高，只要給予足夠的時間，最後都是可以生出來的。
3. 測試工程師為通才性質、廣而不精。
測試工程師這個職位偏向通才性質、廣而不精。在不同的公司或不同的專案中都可能會接觸到不同的領域。在我個人過去接觸過的公司中，就曾做過以下這些超出標準測試工程師範疇的工作：
- 為功能畫原型（一般是由產品做）
- 跟開發溝通功能開發的排程（一般是項目經理做）
- 跟第三方廠商溝通的公司（一般是商務做）
- 回覆業主的線上使用問題（一般是技術客服做）
另有這些是比較進階的測試工程師工作內容：
- 出技術文檔並進行內部工具培訓
- 開發自動化測試腳本代碼
相較於一般的開發通常只熟悉自己負責固定的模塊、測試由於是位於最下游的職位；最終在進行整體測試時勢必會是 以使用者的角度、全局的去體驗整個產品。
因此只要上游的工種（產品、後端、前端）有任何一環出了問題，若是沒有在開發時被發現並即時修正、問題就必然會累積到測試階段才被發現。
現今的測試業界雖然很流行強調：
「從功能規劃階段就開始參與測試」，但實務上相當困難。
我還沒有遇過哪一間公司真正授予足夠時間與權限，讓測試能夠從源頭參與開發的。大多數情況下還是會慣性將問題積累到提測後一次性爆發。
在這樣的前提下，測試往往會需要找不同工種的人員協助排查並定位問題，在討論的過程中與不同的角色學習、因此自然會 對產品的全局有比較廣泛的視野。
但是優劣其實是一體兩面的，有廣度沒有精度往往會形成 對某個領域一知半解 的情況，例如：
- 能定位到問題是由哪端引起，並告知對應工程師應該如何修改，但沒有足夠的能力直接修改代碼使之正確。
- 能夠跟產品討論某個功能的合理性；並分析代碼實現上的困難度。但要從頭寫一整個功能的規格書或者是畫一個完整的原型又辦不到。
總結來說，就是做到最後 各項工種似乎都懂一點點，但是要轉職成該角色卻又在能力上有所不及。
4. 能力需要經驗累積，但容易固化、年資過高非優勢。
手動測試很吃重項目經驗與靈感
在反覆測試熟悉的項目這個過程中，已經把相關功能的前因後果、各種發生過的問題都 內化在腦海中 了，也就是測試時的 「靈感」 來源。
同類型的項目測試的夠久，就算換了公司、常常也能一眼就可以看出可能有問題的地方，相對也容易去評估測試的優先級順序；一回生二回熟、行業中類似的功能其實結構都差不多。
同類產品測久了容易思維固化
反過來說的缺點就是比較容易 固化在特定類型的產品上，通常一個測試主要在測試某類型的產品，後面的工作就容易也是去測試同類型的產品。
例如：遊戲、金融交易產品、電商產品這三大類的測試工程師就相互不容易轉換，可能需要在過去測試過的需求中有沾到一些邊才比較容易拿到 offer。
箇中原因我猜測一來是人傾向於在自己熟悉的領域中工作、二來是徵才是市場也喜愛找過去有測試過同類型產品經驗的人選。
這樣做看似很合理，畢竟要替新項目找適合的測試人員加入時，沒有理由不去選已經懂得行業 Know-how 的人選。
測試工程師年資過高非優勢
當你在測試行業年資已經很高，並且長期測試同類型產品時就更難帶來改變，因為轉換測試的類型需要重新累積項目經驗。
也就表示具有 5 年年資但剛轉換測試類型的新人選，初期表現不見得會表現得比只有 2 年年資的現有測試來的好。
而一般來說年資較高的測試對於薪資有較高的要求，因此當項目運營不善時，年資較高的測試也就容易淪為「又老又貴」的優先裁員對象。
不僅如此，手動測試的天花板本身就比較低，入行短則 2 年長則 3-4 年，基本手動測試的要點已經都可以融會貫通了。
如果手動測試做了太多年都沒有晉身管理層或者是精進自己的技術能力，這時候就彷彿原地踏步；像是國中讀了 10 年一樣，實質上的水平並沒有增加。
相較於開發可以選擇在技術上繼續精進，測試則終就會被迫在「成為管理職」 跟轉向 內卷之路 「學習自動化測試」 之中作出抉擇。
5. 獎勵有限、責任無限
接著我要再說一個關於測試比較沈重的事情：不管再怎麼努力，每次上線成敗都帶有相當大的運氣成分。
測試身在軟體開發流程的最下游，我們舉個極端一點的例子：
假設開發在代碼內有心要埋入一個隱藏的 Bug；身為功能測試的你 (這裡不討論參與白盒測試的情況)，有把握可以百分之百攔截那個 Bug 嗎？
當然不可能。
這就是測試一個很困難的事情：必須對別人做出的東西負責，說難聽一點也就是 背鍋。然而背鍋確實就是測試的核心職責所在。但我們最多只能 減少潛在的問題，無法保證絕對不會有問題。
既然無法 100% 肯定所有的 Bug 都能夠被完全的檢驗出來並修復，那就表示哪怕只有 0.001% 的機率，基本上都是在 賭這次會不會有問題。
如果沒有問題那當然是皆大歡喜，但只要出了較為嚴重的問題、後續的處理方式就非常看公司與團隊老闆的想法了。
說完了為什麼 責任無限 之後，反過來想為什麼 獎勵有限 也不難 ：因為公司已經花錢請一批測試在為品質把關，所以 自然會將潛在損失預設為 0。那也就表示即使測試揪出了所有的 Bug ，讓產品毫無損失的上線，也只是符合預期結果而已；因為測試而避免掉的的損失不會被當成收入來看待。
關於這個主題的延伸閱讀，若有興趣了解更多，詳情請參考：
人人皆卷－軟體測試為何無法停止內卷？
這也就意味著表面上看起來 「測試」 是個無法主動提供產值的單位。我覺得一個公司花錢請測試可以比喻為：
買保險，在有健康風險發生時能協助 cover 部分；
但是沒辦法打包票絕對不會得癌症、或是不會出車禍。
若一個人買了保險之後要夜夜笙歌把自己的健康毀掉；
有保險也只能在生了病之後理賠做為彌補，不能還你健康啊。
(想要擁有健康，還是得好好照顧自己的身體。)
同理可以套用在項目開發過程中測試的定位，如果產品本身已經有許多嚴重問題；是不可能單靠測試就改善的。我個人認為，一個團隊要能真正改善項目品質，需要上下游各個環節一起合作。
如果 產品、開發、測試 之中有一個團隊程度比較差，最終項目呈現出來的結果會等於最差的那個環節的水平，而不是最好的那個。
6. 總結
- 測試工程師的每日工作是否開心是非常看公司和項目運氣的。
- 雖然不可控的因素很多，但對於非本科系想要轉職進入軟體業的朋友來說，不失為一個出發的好選擇，(如果未來想往開發走幾乎是唯一選擇)。
- 手動測試的天花板較低，如果你在測試工作中已經開始學習不到東西；建議趁早轉換測試項目的方向，避免固化。
- 如果你真的熱愛測試，轉型為自動化工程師或者測試開發工程師也是另一個選項；但是以沒有技術背景的朋友們來說，學習曲線確實陡峭了點。
本篇分享就到這裡拉，如果你對測試工程師的實務工作或者相關技能有興趣；還請不要錯過我接下來的其他文章，測試工程師這系列將會持續更新。
延伸閱讀
人人皆卷－軟體測試為何無法停止內卷？