寻找“真因”，对症下药

一、抛出问题
软件质量差，不稳定
客户反馈投诉多
你们测试为什么没有发现？
软件不好用，不方便，不易理解!
二、分析问题
1、这个问题是什么？
RE：保持与客户反馈的问题理解的一致性，确保问题不失真

2、这个问题真实存在吗？
RE：核实问题是否存在，必现还是偶现；

3、如果必现，用例是否有覆盖到？是否有执行，执行的结果是什么？如果偶现，概率如何？
case1：未覆盖
why？测试用例问题

case2：有覆盖，已执行，PASS
	偶现问题，概率几何？
	
case3：有覆盖，已执行，FAIL
	已知问题，是何原因带问题发版？
	
case4：有覆盖，未执行
	测试策略问题，why？测试策略有没有经过评审？

三、结论与解决方案
case1：测试用例未覆盖问题
a.将问题同步到品质群，要求其他项目确认是否存在相同问题
b.将问题转换成项目测试用例，提升后续测试覆盖率
c.将问题导入到经典缺陷库，定期组织品质团队学习库中问题，进行思维复制

case2：概率问题
a.极低概率
将此缺陷转换成测试用例
b.高概率
同必现问题处理方案

case3：已知问题，带问题发版
确认项目组当时发版评审意见即可，责任由各环节共同承担。

case4：策略问题
核实当时的策略是什么，为什么要这么执行？进一步确认问题引入阶段，可参考“客户反馈问题分析思路”

出现bug后，不要直接甩锅，这样让人感觉在逃避问题。第一要紧事情是处理bug，尽量减少对用户的影响；只要用户影响不大，即便有责任后果也不会太严重
那么是不是这口锅就会全部扣测试身上呢，这样明显也是不能接受的，测试人员需要找出足够的证据来保护自己。所以第二，我们一定要对测试后出现的bug进行分析并回溯!!

（1） 通过回溯确定问题的产生原因，问题的责任认定基本就清楚了
问题回溯一般从bug的引入阶段，bug的产生原因，bug的遗漏原因等几个方面去分析。例如：

• Bug如果是需求阶段引入的，需求本身有遗漏/描述不清楚，那么主要是产品人员的责任，但是设计、开发、测试人员没有评审出问题，同样也有责任
• Bug 如果是开发阶段引入的，测试人员设计用例的时候没有考虑到，那么主要是测试人员的责任，但是测试用例同样是要经过开发、产品的评审才会使用的
• bug同样是开发阶段引入的， 如果bug是由于开发修改bug的时候引入了新的bug，恰好那个用例之前测试过，不会再重新测试了，这样的遗漏主要责任就在开发，修改bug控制影响范围是开发必须做到的，但是测试人员可以没有做到代码看护的事情
• 再或者产品人员变更需求后，只是告诉开发要改，但是没有同步给测试，造成测试漏测，这就是项目研发流程有问题了，项目经理要负主要责任。

（2） 回溯并不是为了推脱责任，根据问题原因提出改进措施才是最终目的。
其实出现问题并不可怕，吃一堑，长一智才最重要。针对上面分析的那些问题的原因，需要制定出对应的改进措施，建立可以量化的改进任务，并指定特定的负责人来跟进，避免类似的问题再次发生。
为了减少测试人员背锅的可能，最后提几点小建议：
（1） 做好充分的测试计划
按照正常的测试流程（测试方案、测试用例、测试执行、缺陷回归）来评估测试需要的时间，有时还要预留一些冗余的时间，以处理突发情况，在项目排期时要尽可能的争取足够的测试时间，这样才能保证在测试过程中能够有条不紊的进行。
（2） 测试过程中的所有工作必须有数据记录，不能口头传达
很大测试人员怕麻烦，或者自认为跟产品开发关系好，一些bug通过口头和开发人员说一下，但不提交缺陷报告；或者bug回归不通过怕面子过不去，不给打回；开发人员说这不是bug/不重要/不同修改，然后bug就不提了，等等。这些行为平时看起来无所谓，还省时间，但是到了出问题的时候，就是自己埋下的祸根，到时线上出问题了，你说当时测试过，但是谁谁说不用改，口说无凭！
（3） 测试结束后的总结需要认真编写
正常来说，测试结束后测试人员对于软件质量一定有自己的判断，是否达到质量要求，是否发布上线，哪些地方由于环境、数据等各种原因没有验证充分，还存在风险等等，都需要明确的写出来。例如：在测试过程中出现特殊情况，如开发的版本转测试时间延迟，需求变更等，导致时间不够测试不充分，你可以在测试报告中建议延期发布。如果项目组要求必须发布，那你就在测试报告中写明这些问题，导致测试不充分，哪些地方会有风险。（这些理由如果在测试报告中不写，在问题发生后你再来提，就是“事后诸葛亮”，别人会认为你只是在找借口）
（4） 提升自己的技术能力
提升自己的业务分析能力和用例设计水平，让自己写的测试用例能否尽可能的把需求覆盖全面一些，各种正常异常的情况考虑齐全，就不容易出现漏测；再者，提升各种代码和自动化工具的能力，编写一些自动化的看护脚本，这样即便出现开发修改代码改出新问题，也能够及时发现，提高产品的质量。