※前言
這篇文章紀錄一段青年的轉職歷程，和他轉入軟體產業後的第一份工作。他之所以成為一名測試客服，並不是在知見充足下的理性選擇，也不是在能力範圍之內的領域深造。只是機運之下，混雜著衝勁與熱情去對未知進行探索。
或者你要說，這是一段頭很鐵的楞頭青被趕鴨子上架的拙劣掙扎，我也是能會心一笑。
建議配樂： amazarashi - 戸山団地のレインボー
※轉職準備
2020，冬。
開始接觸程式語言的緣由很實際，只是在網路上找到一些運作有問題的遊戲外掛。由於這些外掛是公開原始碼的開源程式，篇幅也很短小，也就可以生啃網路上的語法文件，一步一步慢慢修。當腳本動起來的時候很愉快，也就開始對軟體產業抱持著好感。
2022，春。
參加了職訓局與桃園某科大合辦的Python開發班，每天八小時總長三個月。結訓後有做出一些簡單的桌面應用程式、架個樸素網站、網路爬蟲，會一些MySQL指令且能使用Tensorflow訓練人工智慧模型。
但終究是只有三個月，我自愧學習的深度並不足以滿足軟體設計工程師的職場要求。
※插播-初學語言選擇
作為一個從Python開始接觸正規語言的學店生，個人認為Python是一門很好的啟蒙語言。它有著好懂易學的特性，在2024的這個當下隨意在yt上搜尋，就能找到很多淺顯易懂的網路教學。靠著數小時的自學，就能捏出一些滿足日常需求的工具。
但同樣也因為這點，很容易成為別人履歷上的其中一項技能。也就不適合作為學店仔的唯一轉職工具。若將Python視為主語言，甚至是唯一的語言，那麼該名轉職仔也就需要更亮眼、更完整的作品展示來爭取工作機會。
雖然學歷高低或是面試臨場表現的影響占比大概也沒比較少，可Python並非轉職最優選的感慨與勸戒，影音平臺上俯拾即是。
不過我畢竟走上的是測試和維運的路，或許也沒資格評論那條並未踏足的隔壁岔路。
※軟體產業的職務
在說明我的職位之前，我先介紹一下一些軟體產業的常見職務。
RD(研發)、PM(專案經理/產品經理)、QA(測試)、DBA(資料庫管理)、FAE(技術服務)、CS(客服)、資安。
上述大部分都可以顧名思義，RD開發軟體、PM管理專案進度、QA保障品質、DBA維護資料庫、FAE對客戶提供技術支援，或者可能兼做CS，接客服電話並追蹤問題。而資安推動或維持資訊安全的認證，並完成公司內外發起的資安需求。
其中，RD可能會再依照工作類型分為前端工程師、後端工程師，以網站來舉例，前端是客戶端能見的網頁畫面與互動效果，後端則是伺服器端處理資料的業務邏輯。
而QA也可能因工作類型而有所區分，韌體測試，測的可能是硬體的驅動程式；前端測試，測的可能是網頁畫面；API測試，則是在測前端與後端之間傳輸資料的媒介，API。
因為有將不同工作進行專業化區分的需求，從而細分出這些職位，呈現在人力市場上。那假如公司在經營業務時並未分割這些工作內容，也就不會受限於上述的職位類別去交付工作。
※公司生態
在這間公司，由四名成員組成一個軟體開發專案的工作小組，業務、專案經理、軟體設計、測試客服。
其中業務由部門的最高管理者兼任、專案經理負責統籌和管理。將餘下的工作分配給另外兩位成員後，實際上為了專案而加班趕工的往往是測試客服，再來則是軟體設計。
所以雖然這份職位的全稱是「測試客服工程師」，但實際接收到的工作包含：軟體測試、技術支援／客戶服務、專案文件、資訊安全，這四種類型的工作任務。
※受訓
就我所知的業界生態，軟體業的新人通常都會有一段或長或短的培訓流程要完成。一是盡量將新人的編程習慣調整成公司已往的風格。二是訓練並驗證新人的技能足夠稱職。三是提供一段熟悉舊系統的時間。
當然，也有可能是四：十幾年前大家都是這麼培訓過來的，所以新人也該承受相同的訓練。
而這段訓練可以從面試開始講起。
2022，秋。
1.面試
(1)邏輯測驗
一頁邏輯推理的簡單測驗。
(2)閱讀測驗問答
閱讀一份軟體的需求規格書，雙面列印約五頁。回答一些理解性問題。例如某某資料選擇停用而非刪除的理由，是因為它可能是其他資料子表的主表項目。
(3)主管問答
由三位不同主管，問答一些應徵理由、想做到什麼、舉例說明合作能力的這類常見面試題目。
2.四道考題
錄取後，發下四道考題。每題預定給予一週的作答時間，若超過時間則請新人離職。
(1)Bug重現
針對一個網頁系統，重現特定Bug的發生情境。在於批量複製時有阻擋動作，但動作不確實導致資料篡位。
(2)優化建議
閱讀四張報表的需求規格，挑出錯誤並給出優化建議。
(3)系統操作
閱讀一個門禁系統的操作說明，操作兩種門禁卡機和網頁系統完成指定類型資料的輸入與匯出。
(4)壓力測試
給一本Visual Studio 2010的工具書，使用此工具進行指定網頁的壓力測試。
我蠻幸運的，兩週內就將上述四道題目做完。在當時，甚至因為作題就能白拿薪水而顯得有些惶恐。
現在想來，這可是極少能偷閒的時光，可惜被我的不安與惶恐給扔至一旁。
3.三本工具書的閱讀報告
發下三本厚如磚頭的工具書。每本預定給予一個月的時間，向指定主管依章節報告閱讀心得。
也是在這個時候，我才結束每天通勤來回四小時的不安，放下心來搬到公司附近。開啟了無止盡的加班人生。
三本書分別為：
(1)SQL Server管理實戰
約為SQL Server本身的管理方法。
(2)資料庫設計
約為T-SQL指令的教學。
(3)商業智慧開發與維護
約為SSIS(資料轉換)、SSAS(多維度資料庫)、SSRS(報表)的使用及管理。
學習是快樂的，而能在口袋裡收著薪水帶薪學習，那是雙倍的快樂。但事後回顧，這三本書的培訓流程其實不太合理。
一是出版日期皆為二十年前，約三成內容已過時或已更新，需要搜尋網路資料來補充說明。二是內容都和MSSQL資料庫和資料管理有關。比起，更偏向是後端工程師的工作技能。
總之，最後在部門領導的催促下保留一些未讀章節，在兩個月內掐斷這份報告任務。
※正式工作
在完成培訓流程後，我從製作教育訓練影片開始，接手三個長期專案的測試客服工作。
專案皆屬標案的好處，是契約中白紙黑字的寫明了工作內容。內容包含著資訊系統的擴充開發、維護和保固。
根據公司與客戶簽訂的契約內容來看，專案的開發流程屬於典型的瀑布式開發。在專案啟動時就將需求訪談、需求確認、開發、測試、部署的日期敲定下來，編列成計畫書，依照日期交付工作進度。就像是由高至低流動的多層瀑布一樣，一步一步的推進工作階段。
雖然維護部分中有給予一部分的程式修改額度，可能會臨時接收到客戶修改程式的要求。但那同樣是給予了一段瀑布式的開發週期，同樣的要完成需求訪談、需求確認、開發、測試、部署的作業流程與文書紀錄。只是在開發難度較小的同時縮短了時程。
而測試客服的工作也是如此，依照契約、計劃書與會議紀錄中規定的日期，完成軟體測試、程式部署、驗收文件、災難演練、帳號清查等工作。
但因為這間公司的「客服」二字，其實意涵要比大眾認知的再擴大解釋，包含了圍繞著「服務客戶」這個概念而生的周邊工作。也就包含著廣義範圍的業務助理、電話客服、技術服務、行政文員、後端助理、資安助理等等的工作。
職位定義以我的猜想，很可能只是公司的規模擴張時，想讓RD專注在軟體開發工作，決定將其餘工作撥給另一位成員，從而建立的職位。
總之，作為公司面對客戶的唯一窗口，其實是一種與人高度相關的工作。也就容易會在一封郵件、一通電話過後，接收到客戶拜託下來的工作任務。
或許是簡單一些的，例如電話說明系統的資料結構、例如整理資訊系統間介接資料的時機與內容、例如調查特定離職員工的操作紀錄；也有時候困難一些，例如分析系統功能的效能狀況並提供改善方案、例如追查防火牆特定port的連線理由。
很多時候是硬著頭皮接下任務，然後用力的撞牆，賭前方那道未知難度的高牆會比我的頭先破。無償加班直到餓的兩眼昏花，才敢下班結束今日份的努力。
綜觀所有的工作任務，可分為下方四類：
1.軟體測試
(1)設計測試案例：根據收到的程式，根據需求規格書和程式隨附的修改通知，設計測試案例。包含功能測試、異常測試、整合測試等多種方向的測試案例。確保程式的功能有滿足需求規格，在使用時不會發生異常。
(2)執行並記錄測試：部署程式在公司內的測試機，透過資料庫指令或系統畫面建立測試資料，執行案例中的測試動作並記錄，回報RD測試結果。
(3)驗收測試：部署程式在客戶環境的測試機，交遞測試報告並請客戶驗收測試，並且追蹤進度。
(4)Bug重現與追蹤：重現客戶回報和自己發現的Bug，將觸發條件整理成文件，回報RD並追蹤修改進度。
(5)收集優化建議：收集並整理系統的優化建議，適時的用於與客戶的對談，或提供給RD作為提案需求。
2.技術支援／客戶服務
(1)部署：在遵守客戶流程規範的前提下，部署程式在客戶的正式環境。
(2)客服電話：接客服電話，解答客戶疑問或是紀錄客戶回報的使用異常。
(3)維持顧客關係：服務關鍵使用者，例如客戶端的系統負責人/管理者。服務項目例如協助對方完成長官交代的報告、說明系統的設定方法、協助從資料庫撈取並未顯示於系統畫面的資料、整理系統間介接的文件等動作。
(4)維護系統：維護資訊系統本身、系統所在的伺服器和系統連接的資料庫。
3.專案文件
(1)登打紀錄：於客戶指定的資訊系統中登打紀錄，例如遠端連線紀錄、維護單、變更單。
(2)會議記錄：會議前準備所需文件、參與會議、記錄會議紀錄。
(3)維護文件品質：適時更新系統文件，例如安裝手冊、管理手冊、操作說明。
(4)驗收文件：根據專案契約的時間頻率與內容要求，製作各項驗收文件。包含弱點掃描、滿意度調查等報驗文件。並執行列印、蓋章、彌封、投遞，和開立公司發票等動作。
4.資訊安全
(1)資安活動：在客戶請來的顧問監督下，執行災難復原演練。依照客戶需求，可能有不同版本的演練方式，包含災演後銜接正式伺服器切換的版本與異地備援情境下的災難演練。
(2)資安報告：定期協助客戶完成資安健診的報告。報告中分析HostMonitor的監測數據，整理並分析多項log(紀錄檔)資料，可能包含：
一. IIS log：微軟可用於架設網站的服務(IIS)紀錄。
二. pfirewall log：架設網站所用的伺服器主機(Windows Server)的防火牆紀錄。
三. AD log：伺服器主機的運作紀錄。
四. AP log：資訊系統本身的運作紀錄。
報告中，將log分類呈現並說明各項數值的成因與解決辦法。
(3)資安文件：編列與維護資安文件。常規文件例如風險評鑑表、資產清冊。或應客戶需求，建立資安強化措施評估表、內稽檢查表等文件。
(4)資安稽核：針對公司軟體開發方與客戶軟體管理方的兩種身分，也就是兩場不同的稽核，準備資料並回答稽核問題，協助完成資安認證的外部稽核。
以上，就是這份工作中需要完成的任務。
事務繁雜而細碎，處理起來很是狼狽。經常像個妥瑞氏癥患者一樣，在低聲咒罵中絞盡腦汁。
且不幸的是，由我對接的客戶機構正好越來越看重資訊安全，導入的規範逐漸增加，也就時不時會提出全新的任務要求。
面對日益加重且缺乏先例的這類工作，公司前輩們是靠常態性的加班來處理。而對於初來乍到的轉職仔我來說，也就需要通宵更多的夜晚。
幸好的是，公司對工作成果的複查少到幾乎沒有，只要能讓客戶點頭驗收，並不關心如何達成的細節。所以還偶爾能偷閒個週休二日。但也因此不幸的是，總用體感來估算該做到哪種仔細程度，這實在不是一個很好的學習體驗。從電話對談到會議現場，很多時候根本分不清客戶是不是僅僅出於同情而點頭收下。
整體固然是辛苦的，但事後回望......大半的工作事項都有隨著時間逐漸熟練。嘗試總結一下的話，大概就是個幸運的楞頭青，恰好能在把頭撞破之前，把面前的技術牆給推倒罷了。
※離職
2023，冬。
加班人生是很好的藉口，但比起公務繁忙，咎由自取的占比其實要高得多。
在懷抱著逃避心態而擅自停藥10個月後重新回診，原先相對輕微的輕度糖尿病已經成了中度甚至往著重度糖尿病而去。
日常生活受到的影響，大概是身體器官的健康值都略幅下降。
肩頸處增生的肉芽、腰部持續疼痛、經常感冒、唾液腺反覆發炎，都是慢性發生的身體狀況，當下只覺得是缺乏運動。
真的點醒我的，其實是第二次確診新冠肺炎的後遺癥。它在痊癒後留下了一點慢性支氣管炎的毛病。
自此之後，身體就經常用咳個半死的方式，大聲的跟我說它需要休息。
※結語
「測試工作的本質，是對他人作品的一種批判行為。你要怎麼證明自己的測試足夠有效？」——2024.某嚴厲詰問但親切指引的面試官
若以未來職場的公司角度來分析，過多的工作項目將帶來差勁的品質呈現，而我這名員工也只累積了粗糙且皮毛的經驗。
又若以包山包海的老練工程師視角來分析，再多的工作也只是在排序後按部就班的一一完成。所有的表現不佳，都只是學不會管理時間的孱弱新人在胡亂呻吟。
在擔任這份職位的初期，我以為測試客服工程師可以顧名思義的拆成三段，軟體測試、客戶服務的工作各半，然後負責一些力所能及的後端工程師工作。
其後的日子所料不差，確實包含著這些段落。但工作量更大的是文書工作和資安任務。兩者粗略的加起來，就超過了六成的工時。
而除開陌生事務的生澀學習，說說工作難度。其實在這段時間裡，最為棘手的還是與人相處。
如何在交遞測試結果時降低RD的反感，才不會讓他覺得我沒資格對他的作品指手畫腳？如何讓客戶暫時接受軟體的不完整，才能搶在時間期限內交付程式而不被罰錢？與客戶往來的郵件該如何用字遣詞才能保有公司的尊嚴，當個站著掙錢的乙方？在會議現場時受到詢問和質疑時，該如何迅速給出簡潔明確的答案，或者如何在坦承能力不足的同時留下辛勤認真的好印象？
雖然每每回首省思，總能在回憶裡找到仍可細品的對話情境。但這份職務已經結束，我也在休息一段時間，換了份新工作後，才著手整理這篇日記。
希望看至此處的讀者朋友可以稍微放心一些。也許......我只是換個地方繼續自虐，也有可能遇見了安逸舒適的小天地。總之，還會有下一份故事。
文末悄悄導流一下我的github，裡面的專案包含我寫過的一些小程式、學習筆記，還有個已經架起來，但還沒想好要放什麼的個人部落格。
--------------------------------------------------
初稿完成日期：2024/12/05
達人