标签：沟通 测试的 计划 stat 出现 inf 加班 original 工作
导读：
我们测试人员承担着“保障质量”的使命，这个使命有时候会导致这样一个现象：
- 当我们测试的某款产品上线后，暴露出一些影响严重的bug。这时候项目团队中第一时间想到的问题是，当初测试人员是怎么测试的？！竟然这样的缺陷都没有发现！他们会从潜意识里忽视，质量保障是全员全流程的事儿，出了事故，并不能仅从我们测试身上找问题。
- 快到约定的上线时间了，但系统测试还没有结束。此时领导问项目经理，为什么到现在还不能上线，项目经理回答说我们在一个月之前就送测了，测试人员已经开工很长时间了，具体情况需要让测试人员来说一下为什么测试了那么久还没结束。
谈到这个话题，也许很多人下意识会想到如何“甩锅”，想着如何把责任撇清。这个方法虽然必不可少，但建议少用。因为一旦出现了质量事故，无论解释的多么天花乱坠，都于事无补，反而容易让人觉得你这个人不可信、不可交。说的越多，越让领导反感，觉得我们在找借口！
换句话说，如果真这么干了，那方向可能就错了。从以下几个方面考虑。
一、测试前进行充分沟通，测试范围和风险
- 跟开发详细确认需求，确认的时候注意方法，比如对方讲完了之后重复对方的意思来确认，回头还可以用邮件的方式让对方再次确认。
- 有邮件的方式把测试范围发送项目干系人。一方面让收件人确认自己的理解是否正确，一方面收件人也会在发现信息错误时进行修正。
- 把风险告知测试经理（或者项目经理），包括质量风险和进度风险。 （可加企鹅群：1039627644一起交流，备注博客就行）
冒烟测试
冒烟测试的目的是确认版本是否具有可测性，避免测试做无用功，这点很重要
三、测试执行中的注意点
把发现的问题全部记录在案，特别是“偶发”问题。这样可以当偶发问题在线上出现时，我们能理直气壮的说，这个问题当初发现过。顺便说一下，有的测试人员会觉得发现了问题告诉研发就可以了，理所当然的认为他们会修改的——我不能完全否定这种做法，比如在项目需要紧急上线时可以这么做，避免走流程的时间浪费。
但是这一行，任务重加班多是一种常态，这很可能导致开发人员忘了你跟他说过这个bug，也可能会导致bug没有彻底修复，而且万一以后这个bug又复现了呢？届时我们想查看当初的原因和修改方式都做不到。
四、测试报告中附加必要的说明
比如要带风险上线，可以在《测试报告》中列出未修复的bug，带风险上线的原因，以及这些对这些bug的规划（可加企鹅群：1039627644一起交流，备注博客就行）
五、怎么规避在“工作效率”方面的黑锅
- 提高自己做计划的能力，具体如何提高可以参考笔者其他文章。
- 记录并汇报因为送测版本的问题导致的测试延期。
- 之前好用的功能在新的送测版本中出现了问题，我们可以考虑是否需要立即汇报并将版本驳回，让开发重新打包。
- 测试执行过程中遇到影响进度的问题立即上报
- 一旦出现致命或者严重bug，并且会（或可能会）导致测试无法进行的问题，应立即上报，避免信息不对称。
- 如果遇到问题不上报，可能会导致虽然你最后出色的完成了测试任务，在领导心中，你的工作也是没有做到位的。
测试人员如何避免背黑锅
标签：沟通 测试的 计划 stat 出现 inf 加班 original 工作
原文地址：https://www.cnblogs.com/yq520/p/13052494.html
