因為已經下定決心中年轉跑道
所以就把這些年的心得寫一寫吧，這也會是我最後在這個板上寫測試的結尾
測試這條路，可以走的可長可久，很多時候問題是在自己而不是在別人身上。
跟很多人一樣，我也是從系統廠的免洗工程師開始的
系統廠十幾年來一直都沒改變的，就是你只要會拆組裝電腦就可以來上班
但問題點就在，你遇到客戶的點跟機會往往才是你更上一層樓的關鍵點
//英文、英文、還是英文。//
在系統廠，英文能力通常決定了你有沒有機會往上爬的第一步
你有辦法用英文書信跟可以溝通的英文跟客戶對談，了解他們的需求
甚至開issue review，那你這部分就已經確定有先機了。
當然現在很多還是靠外商的工程師，如果你想領跟他一樣的薪水，自己加油吧。
*************************************************************
對於測試本身，其實大多數的公司
甚至系統廠數十年如一日的on job training
就是要你去讀test case,不管是好是壞
他只問你理不理解，但從來沒問到底這個哪裡有錯
原因就在，絕大多數的系統廠Test Lead跟Test Manager連黑箱白箱都不一定知道
更別說Adhoc testing這種需要高段經驗才能執行操作的測試
敝人在初入行曾經被抓去救援案子
說被客戶在一個禮拜被抓了超過100條issue
客戶沒說什麼，要你們抓出來補救，當然不會給你issue的內容跟條目
我老闆受不了，只好叫幾個願意配合加班的出來動腦看看問題在哪
結果我進去後才發現，CLI的Boundary testing跟error injection根本沒做
被抓死活該。
更別說後面還有客戶要求特殊環境跟測試手法的案子
這種通常都是urgent, sev0/1, 老闆被咬到快出血了，通常資源都會開無限大
也是你最好練功的時機，反正老闆都已經被拉出來坦了
對於這種問題，其實也凸顯了測試手法的經驗不足，即便這是大案子
就算系統廠壓了一堆經驗跟資歷很深的工程師，還是會因為這種基本的問題打死
但這個問題一直到現在，系統廠還是沒有改變
因為你們看到的那些主管不是我的前後期、不然就是長官，他們一直都沒有改變
對於初入行的測試工程師，我的建議是這樣的
先對你的測試環境有初步的認識，對於黑箱白箱、系統整合這些有基本的觀念
接下來的就是態度問題，怎樣才是一個測試工程師要有的態度
就是會讓客戶覺得不方便的問題，就是問題，一定要修正
如果RD不修，要你藏issue、搓湯圓
一定要嚴正拒絕，因為萬一客戶抓到，寫報告的是你不是他
//擔任測試工程師，你就是公司內的客戶代表，你站的立場越穩才有好產品//
*********************************************************************
接下來的就是所謂的個人測試手法跟環境問題
我一直很在意的就是每個測試工程師有沒有自己的環境這件事情
就跟大學時候學長姐給學弟妹最大的禮物往往都是畢業整包的程式source code
這些測試的累積往往才是你能快速進行測試的關鍵點。
我所謂的快速進行，不是說不遵守Engineering Rigor
而是在最短時間內，做出最快最完整的測試
這樣的做法你要有幾個要件
1.能對問題點有效的分析，手法有RCA、DE、FEMA這類的手法
通常在問題本身其實RCA就夠用、而DE跟FEMA通常在設計testcase比較有用
最快的方法，就是建立一個關聯性矩陣，這樣你就知道發生問題要往哪去走
2.有效的快速複製環境，快速複製的環境除了時間的累積System Image外
最重要的應該是你自己要有一個可以因應個別環境而建立的deploy method
VM或是Ghost是常見的，但這些只能應急，沒有完整的代表性。
3.另外就是Automation，很多人說測試不一定要寫程式，這個說法絕對是錯的
測試一定要會寫程式，不然你會做到死都做不好
Automation可以確保大量測試的正確性、因為它可以被一再的重複使用
這也是測試工程師技術力的代表。
話說回來，你沒有看過豬走路，也至少吃過豬肉，別人的錯你不一定要犯
但別人為什麼犯錯你一定要知道記下來，人家都幫你繳學費了。
//建立屬於自己的測試環境跟手法，一定要會寫程式搞自己的Automation//
********************************************************************
等到你有以上這些東西了，接下來反而是辛苦的開始
接下來我們要提到的，就是test plan跟test strategy
Test Program->核心價值就是 Test Strategy
怎樣在有效的資源裡面用要限的時間跟資源找到最多的coverage
通常都會定義再Test strategy裡面，雖然很多式概括性的論述
但問題點在於這樣的Test strategy會清楚的定義到NUDD，Risk跟相關Milestone
這些東西就要有所謂的Project Management觀念了
但很不幸的，測試工程師要轉測試PM通常腦袋沒那麼快...
剛入門的我會建議用這樣的方法理解
把時程拉出來，Milestone跟Deliverable填上去
把資源跟相關的限制跟Risk都一個一個標上去
剩下就是自己抓出要的人力跟物力了
這樣夠清楚了吧?
Test Program->Test Plan
Program的細項會分成個別的functional plan
而這樣的functional plan又會因為各個不同的phase有著不同的定義
然而在break down成個別plan的時候，你有沒有詳細閱讀過MRD/PRD之類的文件
早期文件上的問題往往是日後最難修，價值最高的issue
對於上面的定義你要有充分的了解，甚至找出相對應的測試手法跟testcase
懶人做法，所有testcase全部Mapping MRD/PRD
Test plan->Test case
剛剛有提到的DE跟FEMA在這邊就可以發揮很大的用處
除了最基本的黑箱白箱、test logic外，其實測試工程師要練最多功的就是
怎麼去寫好一個test case
你要給的是一步一步完整的測試手法，還是給一個線頭
讓每個測試的人可以找到自己的無限可能?
這個其實很考驗自己跟老闆
而且在每個Plan下來的時候
你都還要去一個個review這樣的testcase需不需要修正
至於新科技的Spike這種問題，現在好像都是外商工程師會解決
但我還是會建議你好好的研究別人寫的testcase,這樣才能快速的進步
//最後，我想告訴各位測試工程師，台灣測試考PMP的人太少了!!!
不要再告訴我PMP無用論，我每個徒弟都被我這樣玩到不敢再亂講話 //
*****************************************************************
在最後也是最重要的，就是建立自己的人脈
測試工程師錢少、事情多、時間花得更多
你一定要想辦法存錢去進修上課，利用進修上課去存自己人脈
利用跟客戶哈拉抽菸的機會，多跟客戶聊天
再用作案子的機會，讓客戶能重視你的存在，這樣就有機會翻身了。
//你有基本能力後，賸下就是建立自己的人脈，不要小看這些投資
30歲之後，你都要靠這些東西來幫你翻身//
基本的大概也就是這樣子，別再叫我寫書了......