当产品上线或者开卖的时候，如果没有严重的上线事故或售后问题，那自然是皆大欢喜。一旦有严重的问题反馈，产品、开发首先想到的就是测试部门有漏测。问题已经发生了，紧接着的是应该首先搞清问题，然后制定复现策略，抓取有效的Log给开发人员分析。
不管是测试漏测，还是开发修改引起而测试回归时没有覆盖到（由于不知道修改点导致没有回归），出现线上或售后严重问题，测试部门、开发部门写回溯报告是在所难免了，需要向上面的老大汇报。虽说产品的最终质量不是由测试决定的，但谁叫测试是产品开发的最后一环把关者呢，这个时候，项目、产品、开发都会把矛头指向测试部门。如果是你刚好负责这个项目的测试，那你运气不好，当季度绩效可能没了。
谁也不想产品发布之后出现任何严重问题或事故，但是在负责项目过程中，你自己负责的模块执行测试过程中，是否有做到尽职尽责，不把任何风险压在自己身上而及时抛出求助。
如果你是测试整体负责人，是否有做到以下方面：
- 版本太烂没法管控你是否有邮件向项目相干人员反馈；
- 版本发布前有拿到修改点和研发针对修改点的测试建议；
- 项目的整体测试策略、测试计划是否有拉产品、开发人员一起评估，安排的测试内容是否评审达成一致；
- 各模块测测执行的测试人员技术能力是否能足够支撑该项目；
- 项目测试过程中出现的任何风险自己解决不了，是否有及时Highlight给项目组人员求助；
- 重点模块是否安排的是资深测试人员测试；
- 资源、人力不够是否有找领导协调；
- 当版本发布不按照计划执行时，测试计划是否有调整以有预留足够的测试执行时间。
如果这些你都做了，那问题就不在于你，该做的你都做了，项目出现发布后严重的问题概率会很低，也不大是因为测试环节出现的问题。
如果你是模块执行人员，那是否有做到以下方面：
- 对测试模块的需求是否都有了解清楚；
- 测试用例疑问是否都有确定过；
- 测试执行过程中偶现的问题是否非常重视，有向上反馈经过压力测试；
- 测试过程中上报的Block、Critical问题是否有跟踪开发人员及时修复；
- 模块以前的经典问题列表是否有验证过。
如果在测试执行过程中，所有的点你都做到了，那你负责的模块部分出现漏测的情况基本不会出现。
在平时的工作中尽可能避免口头的沟通，而使用邮件、公司的沟通工具来沟通，当最后出现扯皮的时候就能派上用场了，否则出现问题的时候就比较尴尬了，例如需求的沟通确认。但是也不能仅仅是发邮件了事，而是要持续跟踪，所有的问题都需要闭环结论，不管是最终结果如何，不然发不发邮件又有什么意义呢，最终的问题还是没处理而继续遗留到下一个阶段。
产品的最终质量不是由测试人员决定的，而是由产品相关的所有人员、完善的流程共同决定的。但是作为测试人员，我们要对我们的测试的质量负责，对我们交付的测试报告质量负责。
我们首先要把我们自己的事情做好，然后在完善其它流程，共同推广到其他部门，建立完整的质量控制流程。