软件测试完后还有bug是测试人员的问题吗「软件测试完后还有BUG是测试人员的问题吗」

测试完成后还有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） 提升自己的技术能力

提升自己的业务分析能力和用例设计水平，让自己写的测试用例能否尽可能的把需求覆盖全面一些，各种正常异常的情况考虑齐全，就不容易出现漏测；再者，提升各种代码和自动化工具的能力，编写一些自动化的看护脚本，这样即便出现开发修改代码改出新问题，也能够及时发现，提高产品的质量。