按照我的理解，测试人员对自己的定位，对测试工作的认知高度，直接决定了自己能到达的水平。

 

  第一个层次:找bug

 

        软件开发人员交付给测试之后，测试人员开始针对该软件版本进行测试验证，寻找其中的问题。在这个阶段，能够源源不断找出问题，摸索出自己的测试思路，能够借助自动化工具进行规模和压力测试，都可以获得一定的成就感和能力提升。

 

        软件开发人员因为需要用代码来实现功能，因此具体实现细节上肯定比测试人员更清楚。那么就要求测试人员对于整体方案，还有友商实现更加熟悉，方便集成测试和对比测试。有时候翻看之前的问题单，可能会带来一些思路。

 

        对于测试点的文档化，优点是更换测试人员后，也能根据文档较快上手；缺点是可能会固化测试套路，覆盖不到的就一直覆盖不到。总的来说，随着测试团队规模的逐渐扩充，文档化是必然的演进步骤，“新鸟”总要接“老鸟”的班。另一方面，一定要将新的测试思路持续更新到文档中。

 

  第二个层次:做QA(quality Assurance)

 

        将自己负责的模块，作为整个产品的一部分进行验证。需要熟悉各个模块之间的联系，了解客户一般是如何搭配使用。QA最重要的思想，是树立“自己就是站在客户前面最后一道防火墙”的概念，本着对客户负责，对公司产品形象负责的态度做好测试验证工作。

 

        这要求测试人员对自己公司的产品非常的熟悉，对容易出问题的地方做到心中有数，有针对性地进行强化测试。

 

        个人感觉最纠结的地方就是产品质量和交付日期哪个更critical。测试的时间长一些，一般来说会验证的会更加充分。而站在市场人员的角度来看，当然希望能够更快地交付客户。那么谁的意见最终占上风，取决于公司内QA和Marketing谁的发言权更大，也跟客户对交付质量和交付日期哪个更看重有很大关系。

 

  第三个层次:参与产品定义

 

        这个看起来是对测试工作的“越界”，但其实是对测试人员能力的更高要求。如果说前面两项都是对于"现在"(软件开发人员已经完成的实现)的测试，那么这里就要测试人员对于产品“未来”的走向有自己的见解。小到一个出错提示该如何修改才能言简意赅，大到声明需要添加一个功能可以对产品体验带来较大提升，都是测试人员可以通过问题单来推动产品演化的。

 

        这对于那些有志于从测试转向产品经理的同学尤其重要。