引子
作为全职测试大概有8年时间了，总体来说整个这8年不是一个愉快的过程。其中辛苦可能没有做过测试的人未必能理解。对于一个职场人来说不够愉快的点个人认为大概可能是以下几点：
- 成就感不多
- 个人技术积累不多
- 可供选择的机会相对较少，转型难度大
问题分析
1. 成就感不多
A.决定产品好坏的不是测试
大体可以罗列一下一个好的产品的几个要素：
- 解决了其他人没有解决的重要问题
- 易用，好用
- 扩展性好，定制能力强
- 稳定，bug少
- 性能出色
- 交付快，成本低
个人认为以上几点中测试几乎都无法起到决定因素。测试人可能看到某些新的需求，但是很难从更高层面上来看待产品；可用性上面同样也是一样的问题，可以提出优化的点，但是可能只是点到为止了；扩展性，定制能力，基本上看架构设计和开发的质量；至于稳定，bug少，性能好这个也要看团队了，大体上个人认为还是开发权重高；交付快，成本低，个人认为这块测试有一些权重，而且我认为测试需要投入更多的东西在这个层面
B. 测试人缺少作品，在公司战略里面地位不突出
作为软件行业研发部门的人来说，大体可以认为都是匠人，匠人最重要的是什么？就是作品，那么软件测试人的作品是什么？貌似你做的产品和你关系不大，你几乎没有贡献一行代码；你提出了多少实现了的需求呢？貌似也不多吧，有人说有，那不错，但是站在更高层面上看，你的新需求只是一个点，产品是讲战略的，你和产品战略其实还很远，你当然不服气说，那开发不也就是按照需求开发代码吗，但是有时候有这么一个问题会问开发，这个你能做吗？如果回答是不能，可能暂时就不做了，但是如果问测试，这个你能测吗，如果回答是不能，产品一样做，一样发布;
没有作品，那么在公司产品战略里面一定是低的，公司制定产品战略规划，测试其实是没有任何话语权的。没有战略位置，那么测试地位是一定是不高的，所以影响力相对一定低的，那么薪资一定会相对低的，所以成就感自然会少点
C. 被人认可的机会少
和开发比较起来，花费同样的精力，测试得到的认可会少点；测试一般是不出事的时候没人知道，出事了才知道；所以得到负面的露脸机会要来的多一点，自然认可的机会就少一点。在大公司里面如果需要outstanding，你需要有额外的看得见的东西，但是测试发现bug不是就是你工作的正常范围吗？
D. 被放大了的责任范围，造成测试人能力不足问题被放大
测试的负面消息为什么会机会大呢？一个产品出现问题，第一个想到的就是测试，即使没有关系但是根本无法脱身，哪怕是需求不对，还是会有人问为什么测试没有质疑；哪怕开发修改了一些代码，但是在讨论范围的时候从来没有提起过，出问题时测试还是认为是第一责任人；测试的责任范围被扩的很大，大到大体上超过了很多测试人的能力范围了。
2. 技术积累不够
A.大部分情况下测试训练的不是熟练技术，而是熟练业务
日常工作当中，大部分测试熟悉的还是业务，而不是技术实现的细节；但是当你换了工作你以前熟悉的业务也就不能算你这家公司的积累了
B. 锻炼技术的机会少
大部分测试其实很难有机会写工业级的代码，即使你写自动化测试，其实很多什么更多的堆代码；很少做过好好的设计，或者使用一些设计模式；也很少会用算法；同样更加不太可能深入了解那些开源框架的原理；测试一直都是忙于解决那些重要而且紧急的事情，却很少有时间处理那些重要但不紧急的事情，这个一个硬伤。
C. 开发有design pattern，测试有 Testing Pattern吗？
D. 测试接触面比较广，似乎全部有点懂，但是又不太懂，真要解决难题时，测试可能有用的只有理念了，理念是什么呢，那就是流程，哈哈，自嘲一个，可是什么样的流程呢，流程每一步解决什么问题，测试人都清楚吗？技术积累需要专的，至少有一到两个点是专的，否则谈什么积累
反思为什么技术积累不够的时候，我更加相信测试的责任范围被放大了，为何？一个天天挣扎在对公司重要而且紧急的任务上面，同时认为决定了公司产品质量的职位，居然可能是研发部门平均薪资水平最低的职位，似乎这个结论是不是完全不make sense? 如果领导一直认为质量问题是测试的话，我觉的如果这样反过来想想的话，可能觉得问题不一定是测试了。
3. 机会不多，转型困难
其实以上两点分析，自然会造成第三点，积累不够，经常有负面新闻的人，自然机会不多；没有一个突出特点的人，转型自然也困难，往哪里转呢？似乎都可以做做，似乎又都不能做。。。。。。
改进和实施
以上分析了造成测试不愉快的几个原因，以下就想想如何解决这些，未必能解决什么但是想还是要想的：
1. 积累自己的产品
- 测试需要有自己的通用代码库，自己的作品，软件业的我相信还是匠人的世界，所以有作品和没有作品就表示你是匠人还不是，所以我自己一定要想想写点通用的测试代码；我常常想到像工厂流水线制造产品的时候，其实他们面对的问题和测试遇到的问题是一样的，工厂可以购买通用机器设备来加快生产效率，同时也有自己构建工具来做，那么测试也可以去构建自己的工具来加快交付，整个交付其实就像工厂在大规模生产。 构建测试的工具产品去加快交付！
- 提高自身在交付中的地位，通过自动化测试，持续集成的实施，去加快交付；
- 需要提炼Testing Pattern
2. 更深入的学习
- 深入学习1-2门语言，以及一个数据库
- 熟练使用Linux，常用服务器如Apache，tomcat，jboss
3. 更多的将测试的观点表达
- 不停的讲，质量光靠测试是不够的，需要团队的合作；不停的提醒团队，产品是给客户的，不是个测试测的；要站在更高的层面看产品，而不是通过测试就表示任务完成了
- 不停的去想如何改进团队效率，如何让需求设计到测试用例的设计，执行更有效率；我相信这里有很多事情可以做，如果去更好效率的做端到端的交付，一定需要更好的产品，而不是什么quality center，rational 。。。。。。
