筆者任職的工作是做手動測試跟開發自動化測試工具 ..
但其實 在單位上做最多的事情反而不是這個, 而是支援前線.
這件事情也導致自己單位的大頭認為筆者是吃裡扒外的爛東西, 就把考績往更低分打

由於任職的企業是接專案做測試的, 往往自動化的測試工具都有兩種型態

1. 由客戶端自行提供
2. 筆者任職的單位自行開發製作

不管是哪一種, 操作人員都會遇到很多狀況

狀況: 送測單位認為, 你們是專業的測試團隊. 就不給工具說明或給有問題的工具程式

通常遇到這樣的案例, PM 或工程部門的同事都會寫信在詢問客戶要怎麼做. 但是其實有少數客戶是不願意協助/ 回裝死的信件 在這時候, 求助無門的同事就會私下請筆者協助. 筆者也幫他們解決各種疑難雜症.

筆者協助解決問題的步驟及方式

1. 先查看需要協助的人是哪個種類? PM/ 工程師/ 主管
   • 如果是Technical PM (簡稱TM) 或PM, 筆者會直接把解決的重點跟他們說明
   • 如果是工程師, 筆者會把解決的步驟以簡化的方式直接操作並告知該怎麼做. 如果工程師需要回報給客戶狀態. 筆者也會直接告知, 要寫哪些步驟跟給什麼圖片給客戶詢問就行
2. 釐清問題的種類跟難易度

• 在Linux 中通常會遇到的就是權限問題, 如果是這類的簡單情況. 筆者就會直接把解決方式跟同事分享並請他們寫下來
• 如果客戶提供的測試程式有瑕疵, 筆者會試著先修看看. 如果有找到根本原因, 在修復完成後把修好的版本跟對照組請PM發給客戶再次驗證
• 如果是客戶在信件說明要修改kernel並重新編譯kernel , 但卻只給參數而沒有說明文件時. 筆者會在短時間內先做出PoC 後再請PM 拿去給工程單位做後續測試.

3. 協助撰寫自己看得懂的筆記

• 有不少人每每請教完筆者後, 都不一定會把步驟寫下來或者是寫的東西自己根本看不懂. 筆者在發現這個盲點的時候, 就會把如何做的行為及步驟 自己紀錄完後, 以內部信件的方式發送給對方 或是確認對方寫的筆記是可以自己複製出來的才行

結論:
筆者很不解的是為啥很多單位都排斥願意跨部門做技術支援的人, 這類的人在企業裏頭真的就是被排斥跟上頭看不起, 導致很多案子明明很容易搞定卻因為這類的政治因素被迂迴很久而搞不定