前言：我曾經在軟體業擔任測試工程師 8 年，總共待過 5 間不同的公司；前兩間實體辦公、後三間遠程辦公。回想一下我在測試領域中學習以及耗費的青春其實也不算虛度，還能夠在這裡整理一些關於軟體測試的經驗總結和我所觀察到的產業現況，希望對於想要入行的新手或是已經在這行業裡的朋友們有所幫助。
以下說的很可能看起來有些負面；本篇的主題主要是探討測試內卷現象的根源，內容也都只來源於我的個人經驗與觀察，難免有偏頗之處；如果你所看到的測試團隊、或者公司不一樣的話，那要恭喜你在很不錯的公司裡工作！
軟體測試大實話
軟體測試可以說是進入軟體工程師領域中門檻最低的選擇，初級的手動測試工程師甚至只要會操作電腦、手機就可以展開測試工作了。如果是非本科系畢業又想要進入軟體業或者想獲得「工程師」這個頭銜，測試工程師確實是一個不錯的敲門磚。
但是有優點就必然伴隨缺點，在我看來這個職位最大的問題是：「需要依附著大型公司的產品才能生存，畢竟有產品才會有測試需求」。將來若想要走獨立開發路線，就會相當的困難。即便往自動化發展也是一樣的情況；必須要先有東西測、才能圍繞著該項目發展作品集，且大部分公司的商業軟體並不允許任意公開源代碼，這個限制會使得測試工程師的作品累積有一定的難度。
除了難以累積作品之外，近年來我有感於軟體測試這個行業越來越「內卷化」。也就是說團隊的產出無法向外突破，測試人員時常在內部做一些虛功以保住當前的工作和收入；且這個現象可說是從上至下的惡性循環。
什麼是卷？
－ 在封閉的小團體中，每個人耗盡力氣只為了在群體中「看起來」比別人強。
－ 時常出現在沒有直接獲利能力的團隊中，例如測試、財務、人事、行政。
－ 卷到最後人人精疲力盡、工作滿意度下降；卻沒能解決產品實質上的問題。
測試們內卷的根本原因？
在軟體的行業內、大部分的崗位及工種都有產出可以佐證自己工作上的貢獻，或者有存在的必要性、沒有他們產品將無法運行下去。例如這些：
- 開發工程師：提交代碼
- 產品企劃：提交產品規格書
- 運維工程師：管理伺服器運行
而測試這個工種算是產品上線前的最末端了，在草創時期最晚開工的是測試（必須等產品做到一個可以測試的階段）；公司虧損時第一個被裁員的是測試（都已經要收攤了只需要留一些核心技術人員善後即可），整體看起來並不是那麼「不可或缺」的角色，因此測試們必須要很努力的證明自己在公司裡的必要性。
再者，有一個很現實的問題是無法改變的：我們無法知道「未發生但可能發生的事情」將會產生多重大的影響，因此測試的貢獻不容易量化，但是犯的錯誤卻很容易被量化：
- 某些 Bug 在測試時被發現而得以及時修復：損失並沒有實際發生，因此感受不到這個修復的價值為何。
- 產品帶著測試階段未發現的 Bug 上線，導致公司虧損時：首先被檢視的就是測試部門，而通常損失都可以直接被估計金額。
測試工程師不會去跟老闆說：「Hey, 因為我找到這個嚴重 Bug ，所以替公司挽救了xxx 元的潛在損失，跟 xxx 名用戶的信任。」；就算老闆知道了也只會予以表揚，某些老闆甚至會認為這些是測試應該盡的責任與義務（確實是，這無法反駁）。
基於上述的理由，在我看來測試圈發生內卷幾乎是必然的行為，我們很難對外爭取獎勵：幾乎不會有測試做了些什麼，因而替公司增加了利潤；進而被加薪表揚的情況發生。
因為工作性質的原因，能做到的幾乎就是減少損失，而損失之所以被稱為損失，就是因為他不是「預期」會發生的虧損，因此它應該始終就是不存在的。
內卷入門：蠻力做虛功
既然測試工程師無法用創造產品或代碼來證明自己，因此當公司營運情況不佳、或是測試部門被懷疑都在鬼混時，就勢必需要產出一些文書檔案來證明自己有在做事。
我在各公司時遇過的測試 KPI 評比中大概有幾項可以成為量化的指標，用來衡量一個測試工程師表現是否「積極」，然而這背後存在許多花蠻力做虛功的操作：
創建 Bug ，創造業績
- 開一些沒意義的 Bug : 小到說明文字有沒有句點、前端 UI 差了幾個 px.. 等等都可以是 Bug，開發也很好調整、回歸測試的時候還很簡單，雙贏。
- 真的關於流程的 Bug 或者優化建議因為涉及太多端了，還要花時間討論。還是睜一隻眼閉一隻眼吧，堪用即可。
細拆測試用例，創造高覆蓋率的表象
- 把一條用例拆成 5 條，將用例寫得很零散。（實質上覆蓋率可能無人有時間關心）
- 讓其他人難以復用測試用例，確保在該模塊的測試主導地位。
以是否有把某些用例自動化作為產出標準
- 常常才做好馬上又迭代了，腳本要重寫。
- 自動化是用來檢查已穩定功能是否被改壞，但老闆的期望是用自動化做功能測試。
以加班的時數與配合度決定此人對項目是否有責任心
- 上線前的幾天，每天 Bug 要日清，加班回歸測試全部模塊只能拒絕原本已經排定好的行程、犧牲自己的休息時間。
- 反正今天一定要演出加班的劇碼，上班時間就先東摸西摸一陣，不然對不起自己。
從以上例子可以看出，若測試團隊採用這些評斷方式其實最終實現都流於應付，很難真正有效的解決上線品質差的問題。畢竟測試工程師真正的工作目標是「確保產品品質」；而不是開出很多 Bug、寫出很多的測試用例文件，甚至出很多自動化教學文檔給內部人員；結果產品上線後還是很多嚴重問題。這裡潛在的問題是有沒有「做對的事情，而不是把事情做對」。
我相信帶過團隊的人一定能體會，在一個官僚結構中，很多事情往往只是需要做好表面。更慘的是當我們發現：做好表面真的也就過關了。在這樣的氛圍下很難避免逐漸心態崩壞；畢竟人的天性是懂的趨吉避凶、應該沒人會故意把自己活得很難過吧。
以上也許不限於測試、其他的崗位上也會發生一樣的事情：過多的文書工作，為了留下「有在做事」的證明，因此壓縮了做核心業務的時間。這樣的情況在遠程工作上又更常見，因為無法實體的見到你在做什麼事，因此所有的工作都必須留下有型的「紀錄」，更別說還得加上各種奇葩的遠程考勤制度了。
內卷進階：我樂於學習、創造新方案
當團隊的內卷程度已經進化到「只做文書工作不夠卷」的狀態時，往往就會開始有人提倡引進各種新的技術與工具。測試工程師這個角色無論向左或是向右，都有許多方面可以發展，例如以下：
往自動化發展
- UI 自動化： Selenium, Appium
- 接口自動化：Postman, RestAssured, SoapUI
- 壓力測試：Apache JMeter, Gatling, Locust
往開發端發展
- BDD 測試：Cucumber, SpecFlow, Behave
- TDD 測試：JUnit, NUnit, pytest
往運維端發展
- 運維監控：Prometheus, Grafana, Nagios
- CI/CD：Jenkins, Travis CI
- 容器化：Docker, Kubernetes
測試領域光是主流有這麽多工具，真的是有心要卷就卷不完。並不是說引進新工具不好，過去我自己也常常是搞這些東西的發起人。然而引進這些新技術的目的應該是保障測試的終極目標：「產品上線穩定、效能與功能都符合預期標準」。
也就是說工具應該是為測試需求服務的，只有當產品已經發展到適合引入某些技術輔助測試、引入這些技術帶來的效益大於學習成本以及後續的維護成本時，自動化或者新技術才有存在的價值。不能單單只是因為覺得加入這個技術會很酷，或只是自己剛剛學了一個新工具，就想拿來卷死大家，使用工具的多寡不應該成為評斷一個測試工程師是否優秀的標準。
在我待過的測試團隊中，大部分的測試夥伴原先都是不具有技術背景的。不得不說這樣子的條件確實會導致測試在大部分的開發團隊裡面缺少話語權、甚至感到不被尊重。或許是基於對現況的不滿或者是帶點上進心想要自我突破，往往很容易陷入測試工具的迷霧中不可自拔。
由於學習這些技術確實需要工作時間以外的額外投入，部分也真的能為團隊帶來幫助，通常團隊 Leader 都會予以鼓勵；導致其他人也爭相投入更多的時間來學習額外的工具，但很可能他們負責的模塊根本沒有適用的場景。盲目的投入時間只是害怕自己沒跟上，於是形成了一個典型的內卷現象。
講成這樣，那測試還有什麼活路？
其實活路還是有的，雖然目前我的工作經驗來說，我不認為測試的內卷現象是憑一個人或者一個團隊就可以解決的；即使傾公司之力去優化開發流程，測試的工作性質也難以從根本上改變。但我認為還是可以從以下幾處著手，減少虛工量並維持良好的心態：
將自動化的時間投入在確定可覆用的地方，不執著於實現全自動
- 仔細思考自動化的幅度與必要性。如果你所在的專案時常迭代版本導致自動化腳本維護成本過高的話，可以試著把自動化投入在你每天必須做的流程
- 例如你時常需要註冊 10 個新用戶帳號，維持乾淨的數據以便測試你所負責的功能，與其把每個要測試的功能做成自動化流程，不如先將註冊帳號這個前置流程自動化，需要時再調用即可。
盡可能提高測試用例的易用程度和覆用性
- 如果你的公司不強行要求寫制式化的測試用例，那對於邏輯簡單的測試項目，不如做成一個 Checklist 的形式，文書工作越簡單就越能看出當前剩餘的問題是什麼。
- 在編寫用例時盡量一邊考慮用例復用的問題。實務上有些用例可能幾乎是一樣的：例如：某功能需要確保在不同國家的語言都能正常使用時；這些用例在最初撰寫時就不要將語言相關的內容耦合在用例標題或是預期結果中，只需要在測試時在前置條件上更改語言即可。
意識到人類與 AI 最大的不同，以及自己的優勢
- 在 AI 時代中軟體開發從業人員應該都感受到了自己地位的岌岌可危，測試其實也是一樣的，我相信用 AI 可以寫出最多最完整的測試用例、甚至 AI 開發的代碼 Bug 會遠少於人類開發，能夠具體說明規則的事情 AI 都能做的比我們更快、更好。
- 但是人類擁有「觀點」、「感覺」，AI 卻沒有，因此你的觀點、還有你真實的產品體驗都是無可替代的。我們開發出產品，最終的使用者畢竟是人類，我認為未來的測試的重點可能逐漸從「做出沒有 Bug 的產品」過渡為「如何創造前所未見的體驗」。
結語
感謝你耐心的看到這裡，回顧多年以來我的職場生活、似乎有很大一部分時間都獻給了內卷。寫這篇文不是為了抒發情緒，主要是寫給身在內卷團隊中的朋友們，希望你們不要灰心，一樣的問題也發生在我和其他很多人身上。在這些過程中會有獲得也有失去，既然還走不了，真的要卷就卷些可以帶走的技能；願下一個舞台這些因卷而學的技能，都變成綻放的養分。