测试完成后还有bug,测试人员肯定是有责任的,第一时间要赶紧处理而不是着急甩锅。但是这口锅全部扣测试身上,明显也是不能接受的,关键在于测试人员需要找出足够的证据来保护自己。


 

或许很多人会说测试不可能发现所有的bug,但是这句话在公司老板听来不过借口而已。软件质量由研发团队共同保证,测试人员是研发团队的一份子,而且还是专门负责质量的,你说bug跟你没有关系,怎么也说不过去。

所以出现bug后,不要直接甩锅,这样让人感觉在逃避问题。第一要紧事情是处理bug,尽量减少对用户的影响;只要用户影响不大,即便有责任后果也不会太严重。

那么是不是这口锅就会全部扣测试身上呢,这样明显也是不能接受的,测试人员需要找出足够的证据来保护自己。所以第二,我们一定要对测试后出现的bug进行分析并回溯:

(1) 通过回溯确定问题的产生原因,问题的责任认定基本就清楚了

问题回溯一般从bug的引入阶段,bug的产生原因,bug的遗漏原因等几个方面去分析。例如:

- Bug如果是需求阶段引入的,需求本身有遗漏/描述不清楚,那么主要是产品人员的责任,但是设计、开发、测试人员没有评审出问题,同样也有责任

- Bug 如果是开发阶段引入的,测试人员设计用例的时候没有考虑到,那么主要是测试人员的责任,但是测试用例同样是要经过开发、产品的评审才会使用的

- bug同样是开发阶段引入的,如果bug是由于开发修改bug的时候引入了新的bug,恰好那个用例之前测试过,不会再重新测试了,这样的遗漏主要责任就在开发,修改bug控制影响范围是开发必须做到的,但是测试人员可以没有做到代码看护的事情

- 再或者产品人员变更需求后,只是告诉开发要改,但是没有同步给测试,造成测试漏测,这就是项目研发流程有问题了,项目经理要负主要责任。

通过上面几个例子可以看出,bug的产生有很多种可能的原因,一般情况下,在项目组中不会刻意的强调谁要负主要责任。为了团队的团结,大部分情况下都是产品、开发、测试共同承担责任。

(2) 回溯并不是为了推脱责任,根据问题原因提出改进措施才是最终目的。

其实出现问题并不可怕,吃一堑,长一智才最重要。针对上面分析的那些问题的原因,需要制定出对应的改进措施,建立可以量化的改进任务,并指定特定的负责人来跟进,避免类似的问题再次发生。

为了减少测试人员背锅的可能,最后提几点小建议:

软件测试完后,还有BUG,是测试人员的问题吗?_软件测试

 

(1) 做好充分的测试计划

按照正常的测试流程(测试方案、测试用例、测试执行、缺陷回归)来评估测试需要的时间,有时还要预留一些冗余的时间,以处理突发情况,在项目排期时要尽可能的争取足够的测试时间,这样才能保证在测试过程中能够有条不紊的进行。

(2) 测试过程中的所有工作必须有数据记录,不能口头传达。

很大测试人员怕麻烦,或者自认为跟产品开发关系好,一些bug通过口头和开发人员说一下,但不提交缺陷报告;或者bug回归不通过怕面子过不去,不给打回;开发人员说这不是bug/不重要/不同修改,然后bug就不提了,等等。这些行为平时看起来无所谓,还省时间,但是到了出问题的时候,就是自己埋下的祸根,到时线上出问题了,你说当时测试过,但是谁谁说不用改,口说无凭!

(3) 测试结束后的总结需要认真编写

正常来说,测试结束后测试人员对于软件质量一定有自己的判断,是否达到质量要求,是否发布上线,哪些地方由于环境、数据等各种原因没有验证充分,还存在风险等等,都需要明确的写出来。例如:在测试过程中出现特殊情况,如开发的版本转测试时间延迟,需求变更等,导致时间不够测试不充分,你可以在测试报告中建议延期发布。如果项目组要求必须发布,那你就在测试报告中写明这些问题,导致测试不充分,哪些地方会有风险。(这些理由如果在测试报告中不写,在问题发生后你再来提,就是“事后诸葛亮”,别人会认为你只是在找借口)

(4) 提升自己的技术能力

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

 

---------------------------------------------------------------------------------------------

最后,为方便大家自学软件测试,特意给大家准备了一份13G的超实用干货学习资源,涉及的内容非常全面。

《2021测试开发各机构最新全套教程》:https://pan.baidu.com/s/17jkyGn-Wm-zC6QQLkWjrsw 
  提取码:o94n