测试人员有趣的特质

　　好吧！为了完成这项有趣的挑战，测试人员应该具备什么样的特质呢？

　　首先要有好奇心，想弄清楚事物是怎么运行的；其次喜欢动手试验，想知道尝试使用功能演示时不同的用户场景和试验会发生什么。

　　再次，需要一点胆大精神，不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功的问题解决掉。

　　善于分析，善于学习，事实上，测试人员一直在学习，他们的工作性质要求如此。技术总是在变化，接到的每个项目或多或少跟上一个项目不一样。有时候有很好的文档，有时候却没有，必须问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后得出正确的结论。

　　当然，测试人员也有不好的特质，尤其对于那些经验丰富的人为说，不容易信任人，这是从实践中历练出来的，别人总是告诉他们模块X不需要测试，或代码Y“没动过”，这种信息错的数多到数不清了。所以，就算你告诉测试人员草是绿的他们也要亲自过目才敢相信。当然了，不是所有的测试人员都具备这些特质。好吧！也许你做测试是为了一份稳定的工作来生活。也许你不是“真正的”测试员。

　　寻找测试的乐趣

　　只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员。当一个测试人员运行一大堆已有的测试用例时，容易心生厌烦。可能会快运行这些测试，只是想让他们从眼前消失，这意味者他们可能不会非常关注执行的测试，当然也就不能像认真彻底的执行者一样找出某些问题。

　　很多测试人员觉得单调乏味而不屑运行回归测试，虽然大部分测试员都理解甚至同意回归测试的必要性。

　　一个“真正的”测试人员一定会把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。如果原来的分析实在很棒，寻阿能他们也找不出来太多可有更新充实的内容，进而增加了无聊指数。

　　并非发现的所有问题都可以得到解决

　　虽然，看到这个结果会打击测试人员的积极性，但这是真的。最有经验的的测试人员会同情地拍拍你的肩膀说：地球人都知道事情不仅仅是发现问题那么简单。他们也会充分理解、会力支持你的决定：问题A、B、C 可以不解决，并不会有人对这样的决定怪罪你。拥有多年工作经验的测试人员会说出大家都愉悦的意见，因为他们从这家公司的项目经验中学乖了，知道这样会给他们（以及他们部门）带来最好的质量结果。但是需要记住，他们之所以肯牺牲问题A、B、C ，很可能是为了说服你解决更严重的问题D 和E 。当然，大多数测试员是希望发现的所有问题都能够得到处理，现实总没希望的那么好。

　　测试员只喜欢有趣的缺陷

　　所有的测试人员都会告诉你，缺陷是存在的，然后缺陷就真的存在了。一般来说，让事情变得好玩并非缺陷的数目。比如一个测试人员可以在大的网站应用程序中发现上千个表面错误，就是语句与错别字，给用户看的文本有语法错误，图标上的颜色不对，或都屏幕上有东西位置放得不对。

　　测试人员非常讨厌这样的错误，特别是发现有很多的时候。因为记录这类错误比发现它们所花费的时间更长。而且他们一般属于低优先级，很容易得到解决。对！测试人员就是变态的喜欢让开发员束手无策的问题，这样似乎更能体验他们的能力与价值。

　　不要去预测问题优先级

　　在IT领域经验丰富的前辈会告诉你，某个应用程序的最终用户可能会对你觉得微不足道的问题深切关注。这跟人的“烦恼因素”有很大关系，一个错别字或字体用得不恰当可能不会影响用户的使用，项目组的所有人都认为这是个小问题。但是对于每天要看两千遍的用户来说，“烦恼因素”是非常高的。

　　例一个双击鼠标就可以完成的操作，我设计成了三击，只是多点了一个鼠标而已。这也许有趣，但对于每天操作几百遍的用户来说，他会破口大骂地拿起鼠标甩到地上。这太令人讨厌了。这影响的他们的工作效率，也行效率与绩效、奖金挂钩。

　　测试人员报告他们发现的一切问题，其中经验丰富的人员会根据其理解来报告严重程度，但一般来说不要试图预测业务优先级。他们理解中的业务优先级通常就像开发团理解的一样，是不太完整的，并不是基于用户的个人体验做出的。经常有用户愿意“将就”使用有严重错误的代码，却在最后一刻强迫要求修改或添加看起来并不重要的东西。

　　测试人员的工作是寻找、发现、报告，而不是用神一样的能力去评判，测试人员应该随心所欲的提供他们的专业意见，事实上，项目组的所有人都应该随心所欲地提供专业意见。