因为已经下定决心中年转跑道
所以就把这些年的心得写一写吧，这也会是我最后在这个板上写测试的结尾
测试这条路，可以走的可长可久，很多时候问题是在自己而不是在别人身上。
跟很多人一样，我也是从系统厂的免洗工程师开始的
系统厂十几年来一直都没改变的，就是你只要会拆组装电脑就可以来上班
但问题点就在，你遇到客户的点跟机会往往才是你更上一层楼的关键点
//英文、英文、还是英文。//
在系统厂，英文能力通常决定了你有没有机会往上爬的第一步
你有办法用英文书信跟可以沟通的英文跟客户对谈，了解他们的需求
甚至开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岁之后，你都要靠这些东西来帮你翻身//
基本的大概也就是这样子，别再叫我写书了......