在工作中经常遇到当产品上线出了bug后，第一个受到指责的是测试人员，”测试为什么当初没有发现这个问题呢”，这种情况在现实工作中数不胜数，也许他们把测试人员当”超级魔法师”了，经过测试之手的东西就完美无瑕了，这就属于角色定位问题，当定位好自己的角色后，在协商角色内容时，就有了在可能出现的任何情况下现的问题时首先确立对自己预期的基础。

一、善于提出问题

测试人员在需求分析或者在测试过程中不问问题，不是不能测试，只是不能更好的测试，问问题是测试人员对项目发挥作用的基础，不问问题，测试就没有目标，思路不够开阔，分析不透彻，只是呆板的机械的测试固有功能，之前听阿里一位同事讲过，他们在发布的任何产品的测试报告中必须体现出项目的风险点是什么，如果不思考不分析，风险点是不容易提出的，那么测试意义就会打折。

二、与开发人员高度配合

为程序员提供支持，才是测试员使命的关键部分，当程序员还在编写代码或者编写完成待提测时，必要时测试人员能够提供测试工具为开发人员快速验证使用，而在程序交付后，应该马上启动测试(当然前期测试准备工作需要充分)，尽可能建立最短、最快的反馈环路。力求当程序员还在苦苦思索上个bug如何解决时，测试已经开始寻找更多的程序问题，最理想的状态是程序员为了修改bug团团转，是程序员而不是测试人员成为项目的瓶颈，降低项目潜在风险。而且这里可以加一点测试人员的角色，就是对bug定位问题，不能只看问题现象，需要深入问题本质，一层一层扒开它的面目，为开发人员节省时间，缩短bug生命周期。

三、认清重点

测试员不会发现所有的问题，测试员的任务就是找出并报告重要的程序问题。那么假设一下，为了发现程序所有的错误，测试员必须检查所有可能有问题的地方，要在有可能发生的不同条件下观察这些地方，还需要一种十分可靠的方法，当所有类型的错误发生时，你都能够识别出来，那么如果一个测试人员能做到这些，要么是这个产品特别简单，要么测试员的想象能力有限。当我们知道并承认自己不能做所有的事之后，测试员必须选择如何利用自己的有效时间。

经验总结：迅速找出重要程序问题:

1、首先测试变更的部分，然后回归老功能，识别新变更带来的风险；

2、首先测试核心部分，即关键和常用功能；

3、首先测试功能，再测试可靠性，考虑各种异常场景；

4、具备判别bug风险等级的能力；

等等

当然这里要求测试人员对产品有绝对的熟悉了解，更快捷的找到问题；

四、测试不能保证质量

测试人员不是质量卫士，测试既不会提高质量，也不会降低质量，质量好不好代码底子就在那里，质量源于构建产品的人，听起来很不可思议，但这也是他们要背负的沉重负担，测试员使命中另一部分就是帮助他们对付真正的负担。但如果测试员认为自己是项目团队中唯一关心交付好产品的人，就不能很好的完成这个使命，说明测试员没有认清自己的角色，测试员的测试和错误报告提供了促进质量保证的信息，而最终保证质量的是整个团队。所以测试员永远不要做看门人，否则是对整个产品的不负责任。当你扛起整个产品质量的全部责任时，团队的其他成员可以放松一点，甚至会大大放松，如果问题遗漏没被发现，其他成员想当然的会来指责你，为什么你没发现问题呢，并且同时伴随的还有对你工作量的质疑。

这里再举个例子，曾经待过一个敏捷团队，在那里从来没有上述问题，为什么呢？因为如果线上出问题，首先找到的是相关的开发人员，他要付最大的责任，那么你就奇怪难道测试员就一点干系没了？非也，测试员有测试团队自己的考核标准，会从自身找问题，自然也不会轻松罢了。而这种模式的利好在哪里呢？利好在于当开发人员在写代码时候，他就会考虑到质量问题，如果出bug即便测试员没发现，他们也脱不了干系，那么在接下来的测试工作中，开发人员起了很大的推动作用，这样就整个团队就达成了一个目标，整个去保证质量。

总结：质量是需要团队的所有角色参与者一起分担的。