喜欢和不喜欢的、可做和可不做的事情做的次数多了后就越来越在行了。就小明的工作来说，工作内容其实不算复杂，主要就是看需求，写测试用例，执行测试，报告缺陷。但很多事情要会做并不难，难的是做好，做到极致，这需要时间，并且用心。
学习、分析需求是很重要的一个环节，也可以说是测试工作的起点。对需求的理解是否全面和透彻将直接影响后面的测试用例设计，从而最终影响测试的结果，同时，学习、分析需求也是测试工作的开始，现实中有不少问题都可以在需求阶段暴露出来，比如描述不清楚的业务、逻辑矛盾、开发同事理解偏差等。当然，有些公司有需求评审、测试用例评审的工作。对测试人员来说，准确、充分理解需求尤其重要，需求上说"一"，除了理解 "一" 之外还要考虑 "一" 的邻居 "零" 和 "二"，甚至还要考虑亲戚 "四" 和 "六" 等等。小明在工作的几年中，从最初只能看到需求的80%，到能够看到100%，再到大于100%，也经历了一个略微漫长的过程，其实这也就是所谓的经验的积累。
相对而言，编写测试用例是一个比较有技术含量的工作，这也是小明工作之初的"痛"。一份还看得过去的测试用例，首先要很好的覆盖需求，既不遗漏也不能冗余，描述要清晰有条理，测试用例文档要美观准确，结构要合理便于执行等等。对一名新手来说，小明在编写测试用例之初遇到的主要问题就是测试用例文档本身有不少错误，覆盖率不够，但这些问题都是可以通过不断的学习和锻炼得到改善的，只在于是否足够用心。从最初时拿到需求后不知从何下手、漏洞百出，到现在基本能信手拈来、应付自如，小明也是一步一个脚印加一把汗水慢慢走过来的。
一般来说，执行测试反而并没有太大的难度，如果测试用例写得足够好，跟着测试用例一步步执行就差不多了。但也并不是说执行测试就没有任何技术含量和技巧可言，首先，我们不能保证总是执行自己编写的测试用例，所以测试用例中的思路很可能跟自己的不一样，这样执行测试时是会影响效率和质量的；其次，即便是按照自己的思路编写的测试用例，也可能在执行时才发现并不能顺利的执行，因为编写测试用例时很可能会有考虑不全面的地方，比如一些流程性的用例的先后顺序；最后就是实际测试场景中很可能会有事先没有预料到的事情发生，这时就需要适当的调整测试思路。如果只能一味的按照测试用例文档执行测试的话就很容易给测试结果带来影响，这些影响可能是测试不充分、测试冗余、测试效率不高等。而这一切都是小明深有体会的，说白了实际上没有真正简单的事情。
上面说的几点都是有硬性要求的工作内容，它们体现的是硬实力。而现实工作中往往也需要软实力，甚至很多时候软实力比硬实力显得更加重要。团队协作、沟通技巧、领导才能、责任心等等都可以看作是软实力，这也是很多初入职场的小白们容易忽视和不屑的，小明也不例外。作为一名测试人员，小明最初的想法是，做好自己的本职工作就行了，也就是测试，至于其他的，如和同事相处、培训、沟通等等都不是自己需要负责的。但现实是，小明情愿不情愿的也参与了不少曾经认为不是自己的工作的事情，如带新同事，给新同事培训，写一些总结性的资料文档等。结果就是，虽然有很多事情是自己不情愿做甚至是排斥的，但也确实从中学到了一些只做份内的事学不到的东西，综合能力得到了很好的锻炼。比如培训，实际上培训的内容倒不是最重要的，重要的是能体会到作为听众时体会不到的东西，而这些东西都是很宝贵的经验和经历。
小明一点都不特别，甚至比大部分的普通人还要普通，小明的成长过程也谈不上曲折离奇或者一帆风顺，作为人群中永不起眼的那一员，小明接受了自己的平淡无奇，因为小明明白，很多大风大浪其实都只在于我们自己的内心，而不是纷扰的外部世界。
所以很多时候我们都只是在，也只需要跟自己较劲，你不需要跟任何人比，而只需要不断做一些自己认可的事情，一旦认准了就去勇敢的捍卫，慢慢你会发现，你不仅是唯一的你，而且是低估了自己的你。