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