测试工程师怎么甩锅!

如果说到最困扰软件测试工程师的几大问题,我们最先能想到的无非是以下几点:

需求带着小姨子跑路啦,没有需求我咋测试啦。。。

开发牛皮哄哄啦,他打了我,还说我报的不是BUG。。。

测试时间不够啦,项目质量这么烂怎么还要上线啦,人家不要面子的吗。。。

还有,今天又有人问我,‘这个Bug你怎么没测试出来呢?‘。。。

 

没错相信每一位测试工程师都经历过这样的苦恼,那就是背锅

怎么别的小哥哥小姐姐都是C位出道,我们却他喵的是背锅位出道。。。

测试工程师怎么甩锅!

 

做为一个测试工程师,背锅你怕了吗。今天我们就要拉起横幅,贴起大字报:对背锅说不!

不想背锅怎么办哦,躲在桌子底下也躲不过去的样子。那要怎么办?很简单,甩锅!

 

下面我们就来教大家怎么甩锅:

首先,我们的前提是,你的本职测试工作要高质量的完成。

如果说测试覆盖的不足,粗心大意导致我们遗漏了重要问题,被带入了后期阶段甚至是上线以后。那么我们首先要想的不应该是甩锅和推卸责任

那么第一件要做的事情就是对问题进行回顾,分析到底类似这样的问题遗漏,究竟是不是由我们个人的工作失职所造成的。

如果确实我们确实在测试过程中由于自己的失误而带来了问题,那么我们应该勇于承认自己工作的不足,并对相关利益相关方表达诚恳的歉意。

承认问题还不是最重要,更重要的是我们要主动去总结在事件发生过程中我们的失误所在,并提出改进的思路和方法。所谓亡羊补牢为时未晚,这样诚恳和负责任的态度相信会帮助你去缓解工作失误所带来的指责和信心缺失。一般来说,如果不是重大失误,我们的团队也不会过多的追究这种问题。

 

其次,我们可以去对事件发生的过程进行流程上的回溯。

我们的测试不是独立存在的事物,我们的测试团队也不是独立存在的团队,我们测试活动也是环环相扣的一种链条式工程。测试工作是研发团队里依赖性最强的工种,我们最终工作的产出,与我们的上游流程的完备程度是息息相关的。

那么在发生事件的过程中,如果我们在回顾自己的测试工作过程中,确实没有发现自己工作的明显失职,那么我们就要回溯到我们工作的上游,看看是不是哪个环节最终导致了问题的发生

测试执行工作的上游工作是什么,从近往远来说,就是:测试设计,测试分析,测试计划,编码开发,产品设计,产品分析,项目需求。

这其中任意环节如果出现问题,甚至可能只是小瑕疵小波浪,都有可能在下游发展成洪涝。

比如说,一个具有二义性的需求,就可能导致开发和测试对于某个功能点有着完全南辕北辙的理解。那么最终这种理解的偏差,就会体现在测试的实现上,造成最终环节的问题。

又比如说,在测试计划的阶段,也许就对测试的覆盖方面估算不足-比如丢失了可用性测试内容-最终导致测试执行阶段对产品某方面特性质量把控的缺失。

所以,我们可以去回溯我们测试执行的上游流程,找出导致问题的根源所在。进而我们需要将我们的发现,合理的去阐述给我们的管理团队直属领导,只要我们的依据属实,相信就可以减轻我们对于事件的责任,更好的一个情况是还可以促进项目流程的改进,防止以后出现类似问题。

当然,在阐述的过程中,一个诚恳和中立的态度是有帮助的,毕竟你有可能将加之于你的指控,导向了另一个环节或个体的工作上去。

 

再次,我们要摆事实,讲道理

我们要知道,测试本身就不是万能的,不是完美的。我们的测试七大核心原则中也强调,我们不应该追求一个完全的测试(即找到所有问题)。

我们的测试过程本身是一项系统工程,它本身就是有局限性的。比如我们的测试执行,每次执行的轮次是有一定时间鸿沟的。在现在的软件开发大环境下,持续集成的理念被广泛应用,系统的迭代和增量每天都在发生。这些迭代和增量每一个都有可能对我们已测过的功能产生冲击甚至造成破坏,我们的测试不可能每天都跟随的代码更新去覆盖,就算使用非常高水平的自动化测试去覆盖回归测试,也是避免不了在我们测试完成之后,系统功能又被破坏的。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyjpgy.html