掰着手指数，做测试这份工作已经六年了，年纪也一大把了，和出来抢饭碗的90后拼体力已经拼不起了，所谓”人老奸，马老滑“，拼不起体力，那只能拼巧劲儿了。

　　巧劲儿也不是那么好拼的，那也得有扎实的基本功才能，什么测试的理论、方法、胆大心细、逆向思维啦什么的，会点语言写点代码、会个工具忽悠忽悠外行。。。。。。

　　铛、铛、铛、铛。。。巧劲儿大比拼开始

　　行业知识的深入理解。深到一个什么程度 ？行业老专家的水平---这个当然达不到了，达到小专家水平那还是必须的啦。新手在那里猛戳猛点功能的时候，你就可以喝着茶水悠哉悠哉的执行一条他戳死也不会知道的测试用例，然后迎接他无比崇拜的眼神了。达到行业专家的水平好难啊，公司又不会出去让你去客户那里接受培训（一般的培训好像也都是概念上的东西，核心的东西貌似都不讲出来的），即使有这样的培训也轮不到一个人微言轻的小小测试人员的。那就只能自力更生多听、多做、多记，别人在讨论的时候就竖着耳朵听，然后拿本本记，工作的时候总有是与自己不相关的工作要做的，那就接受去做，然后整理记录，如果你一定要分清你的我的他的，那就丢失了学习的机会，学习是不会时间地点地，然后还是要拿出本本记上，日久天长，就会成为专家了^_^。如果你非要把耳朵堵上，眼睛闭上，那神仙也没辙。

　　（曾经有人问，在公司里知道公司最多事情的人是谁，答案ABCD一堆，正确答案是“保洁阿姨”，因为保洁阿姨要打扫卫生，无论高级领导的办公室还是底层码农的工位她都会去，左听一点，又听一点，最后她知道的事情是最多的。）

　　准确的分析能力。这里的分析并不是分析业务分析功能，而是分析团队，分析团队的整体氛围，每个人的做事风格，有了这些才能对症下药，量体裁衣。如果团队整体是比较刻板循规蹈矩，你上去就要弄点新花样，那非炸锅不可，估计您老人家也呆不长久就得拍拍屁股走人，即使会再牛X的工具，懂再先进的理论也没用；老大愿意放权，那就向他要权获取资源，然后做事；有人强势，那就绕开风头干活，非要顶牛，龙卷风过后只会留下一片狼籍；某个开发人员的质量意识比较好，就可以少花些精力在他的模块上，某个开发人员的质量意识很差，认为有测试的给他兜底儿，他只管敲代码就够了，代码敲的对不对他不管，那对他提交的模块就要小心了，要精心验证他的模块，还要适当的敲打敲打，让他知道他才是对质量负责的人。

　　帮助开发人员获得他对你的尊重。大家都在一个屋檐下，被人轻视的日子不好过，局面不好扭转但并不是不能扭转。告诉开发人员你知道但他不知道的，这个很容易做到（对某些人好像也是很难），开发人员写代码只会关注自己那一块的代码，有可能很长时间一段时间都在写一个业务相关的代码，懂的业务也就那么一点点，测试人员不一样，测试的时候会将整个业务串连起来跑，谁让业务总是有关联的呢，特别是测试的项目与其他的项目有关联，对其他的项目也得了解一二，否则你无法保证测试结果的准确性，这又提供的学习的机会。还有可能今天在这个项目组，明天又被调到的另外的一个项目组，是坏事但也是好事，项目接触的多了，知道的也就更多了。在业务上告诉开发人员他不知道的，现在这个项目的这个接口与另外那个项目的哪个接口有关联，是怎样的一种关系，他会感激你，久而久之他会尊重你，业务上有拿不准的地方会先来请教你，是不是有一种高高在上的感觉了。想要获得这么多，秘籍只有一个，多听多记。

　　与人协作，借力打力。一门心思自己冲，累死事情也做不完，总得有点四两拨千斤的时候。写好一份配置文档，找来一位新同事请求他帮忙验证，即省力，又可以让他熟悉系统，一举两得。

　　知识分享。大家所属的项目组可能是不一样的，但是所需的测试技能却是可以通用的，了解了一个新的理论和方法，学习了一套新的自动化测试工具，分享给其他的做测试的同事，来而不往非礼也，他们分享的方法和技能也许正是你想用的，三人行必有我师焉。

　　微创新。这个词儿太火了，有人在用看板来跟踪项目进度，是不是也可以改造一下，做个BUG看板来影响一些人的质量意识。（微创新这玩意儿要看好当下情况，弄个不好就成了摆设，被人唾骂了）

　　最后，打杂、打杂、再打杂，带着一颗打杂的心到处打杂。