测试需要不一样的情怀
开发拒绝修复我发现的缺陷。理由大体上有两类：一，太简单不想弄。二，太复杂不好弄。那么作为测试人员如何让开发人员修复这些问题？对于第一种情况，首先要分析如果这样的系统让老板去看的话他会不会介意。如果他介意，显然要好处理很多，在茶余饭后向老板提及这样的担忧。征询他的意见。在同意的情况下，在缺陷评审会议上表明态度。措辞上可以这样表述：作为质量验收人员我们很苦恼，类似于这些小问题我们想听听大家的意见。我们先把觉得可能有问题的地方给大家看一看，然后定一个标准。如果大家觉得没有必要修复，后续我们会形成文档请老板批示。后续类似问题一切按照批示执行。这样一来，简单的问题基本上都能合理解决。也不会形成冲突。对于第二种情况，一般解决办法就更轻松了。在风险提示的例行邮件中，作为风险提示。口气上站在开发的角度上分析。（尽管你内心觉得这个不是很复杂）只要告知，如果按照变通方案处理的话，会带来的问题。然后把开发人员的解释录入缺陷管理系统。往往向这样的问题累计到3个的时候，开发的负责人一般就坐不住了。因为任何一个团队都不希望被弱视。这两个解决办法都是通过心理战达到推动缺陷的目的，而且会形成团队合作的良好风气。个人不建议测试人员和开发人员的发生正面交锋。
需求评审会议需要非凡的耐心和钻研精神。在开始评审前，需要做如下准备工作。了解商业目的。功能点内容。有无类似项目。在评审会议上测试人员，要有会议核心内容提示和相关内容记录的专业素质。比如：项目开始时间结束时间；项目参与人员；活动规则；项目健壮性；运营人员操作流程；客户操作可能出现的问题；技术框架采用原则等。在心理上把自己定位为公司领导，流程上要学会角色转换。这样才能提出较有建设性的意见和创新性要求。让业务方觉察到，业务需要合乎市场法规，符合质量规范。
如何处理别人的不解呢？作为测试人员，被问询和责难的机会要远远大于任何一方。往往很多测试人员会据理力争，在办公场所弄的乌烟瘴气。个人认为，这样的做法很失风度，而且会让人觉得很难相处。一方面我们虚心接受，化解矛盾。考虑后续如何避免类似的情况发生。另外，最好在冷静后找个机会，把问题发生的原因给大家说明一下，向大家征求意见。放低身段就事论事，这样的话很多问题都能化解。你会争取到一个朋友，后续当对方发现你的问题时也不太会故意刁难。要相互理解和尊重。尊重你的对手就是尊重自己。
领导往往会把外围的投诉建设性的和测试工作不到位关联起来。这样的悲剧经常发生在我的周围。当我遇到类似的情况时，通常会先把责任承担下来。然后分析判断事情的缘由。如果果真是测试不到位的，一定不会忘记请大家喝茶。倘若不是我方的问题，3天后视情况找领导沟通。说明细节情况。比如：需求变更；需求影藏；测试案例评审时参与方没有指出；回归测试时问题消失上线后问题发生；配置文件线上环境错乱；硬件问题；受到攻击等。当领导发现你做的很多的研究和推演，后续一定会大力的支持你的测试工作，显然也不会再随意关联了。我们要学会赢得领导的信任。
再晚，也要发布测试报告。当你严格要求别人的同时，一定要严格要求自己。测试报告作为质量判断和上线与否的重要依据，毫无疑问的重要地位没有理由忽略它的存在。心理上，测试人员要看重自己的份内事。
版权声明：本文出自 arnohan 的51Testing软件测试博客：http://www.51testing.com/?584386
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
