测试完成后还有bug，测试人员肯定是有责任的，第一时间要赶紧处理而不是着急甩锅。但是这口锅全部扣测试身上，明显也是不能接受的，关键在于测试人员需要找出足够的证据来保护自己。
或许很多人会说测试不可能发现所有的bug，但是这句话在公司老板听来不过借口而已。软件质量由研发团队共同保证，测试人员是研发团队的一份子，而且还是专门负责质量的，你说bug跟你没有关系，怎么也说不过去。
所以出现bug后，不要直接甩锅，这样让人感觉在逃避问题。第一要紧事情是处理bug，尽量减少对用户的影响；只要用户影响不大，即便有责任后果也不会太严重。
那么是不是这口锅就会全部扣测试身上呢，这样明显也是不能接受的，测试人员需要找出足够的证据来保护自己。所以第二，我们一定要对测试后出现的bug进行分析并回溯：
（1） 通过回溯确定问题的产生原因，问题的责任认定基本就清楚了
问题回溯一般从bug的引入阶段，bug的产生原因，bug的遗漏原因等几个方面去分析。例如：
- Bug如果是需求阶段引入的，需求本身有遗漏/描述不清楚，那么主要是产品人员的责任，但是设计、开发、测试人员没有评审出问题，同样也有责任
- Bug 如果是开发阶段引入的，测试人员设计用例的时候没有考虑到，那么主要是测试人员的责任，但是测试用例同样是要经过开发、产品的评审才会使用的
- bug同样是开发阶段引入的，如果bug是由于开发修改bug的时候引入了新的bug，恰好那个用例之前测试过，不会再重新测试了，这样的遗漏主要责任就在开发，修改bug控制影响范围是开发必须做到的，但是测试人员可以没有做到代码看护的事情
- 再或者产品人员变更需求后，只是告诉开发要改，但是没有同步给测试，造成测试漏测，这就是项目研发流程有问题了，项目经理要负主要责任。
通过上面几个例子可以看出，bug的产生有很多种可能的原因，一般情况下，在项目组中不会刻意的强调谁要负主要责任。为了团队的团结，大部分情况下都是产品、开发、测试共同承担责任。
（2） 回溯并不是为了推脱责任，根据问题原因提出改进措施才是最终目的。
其实出现问题并不可怕，吃一堑，长一智才最重要。针对上面分析的那些问题的原因，需要制定出对应的改进措施，建立可以量化的改进任务，并指定特定的负责人来跟进，避免类似的问题再次发生。
为了减少测试人员背锅的可能，最后提几点小建议：
（1） 做好充分的测试计划
按照正常的测试流程（测试方案、测试用例、测试执行、缺陷回归）来评估测试需要的时间，有时还要预留一些冗余的时间，以处理突发情况，在项目排期时要尽可能的争取足够的测试时间，这样才能保证在测试过程中能够有条不紊的进行。
（2） 测试过程中的所有工作必须有数据记录，不能口头传达。
很大测试人员怕麻烦，或者自认为跟产品开发关系好，一些bug通过口头和开发人员说一下，但不提交缺陷报告；或者bug回归不通过怕面子过不去，不给打回；开发人员说这不是bug/不重要/不同修改，然后bug就不提了，等等。这些行为平时看起来无所谓，还省时间，但是到了出问题的时候，就是自己埋下的祸根，到时线上出问题了，你说当时测试过，但是谁谁说不用改，口说无凭！
（3） 测试结束后的总结需要认真编写
正常来说，测试结束后测试人员对于软件质量一定有自己的判断，是否达到质量要求，是否发布上线，哪些地方由于环境、数据等各种原因没有验证充分，还存在风险等等，都需要明确的写出来。例如：在测试过程中出现特殊情况，如开发的版本转测试时间延迟，需求变更等，导致时间不够测试不充分，你可以在测试报告中建议延期发布。如果项目组要求必须发布，那你就在测试报告中写明这些问题，导致测试不充分，哪些地方会有风险。（这些理由如果在测试报告中不写，在问题发生后你再来提，就是“事后诸葛亮”，别人会认为你只是在找借口）
（4） 提升自己的技术能力
提升自己的业务分析能力和用例设计水平，让自己写的测试用例能否尽可能的把需求覆盖全面一些，各种正常异常的情况考虑齐全，就不容易出现漏测；再者，提升各种代码和自动化工具的能力，编写一些自动化的看护脚本，这样即便出现开发修改代码改出新问题，也能够及时发现，提高产品的质量。
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取