项目上线前出Bug,测试人该如何调整心态
-
当你在测试阶段最后两天,发现测试执行情况不理想,和预估的进度相差较大时,是否会焦虑到不知所措?
-
当你在上线前发现一个严重的问题,修复后需要重新执行一些验证测试及增加回归测试,此时你是否会惊慌?
-
当最后一轮测试/最后一天测试时测试环境突然出现问题,导致测试阻塞,测试进度受到影响,你是否会急躁?
问题描述
即使前期测试准备工作都做的非常充分,测试设计和测试阶段都比较稳,也有可能会出现评估不准确或者中后期才发现重要问题的情况。
因为测试执行工作毕竟是在项目的下游阶段,不稳定因素较多,临时状况也是无法避免,并且项目时间都比较匆忙,在这一阶段出现临时状况往往没有太多缓冲时间给我们。
遇到这些情况,需要及时向项目组反馈当前情况及项目风险,而不是拖延到最后一两天再处理。但是当项目不允许延期,组内也无其他测试同学支持时,我们还能怎么做呢?周围有的同学在这个时候就焦虑的不行了,越焦虑效率越低,效率越低就越焦虑,时间一分一秒的过去了,除了增加血压和心率,项目上线风险并没有任何改变。
测试同学要做的不仅是提出问题,反馈风险,更重要的是提出解决方案,应对风险。越是这种情况下,越是要沉着冷静、条理清晰,结合我们的经验和业务能力去降低上线风险。
解决方法
首先要做的是确定当前已知的风险。当前出现的问题是否会带来风险,以及会有什么风险。如果自己无法确定,可以找其他测试、产品或者开发同学一起评估。
有的测试同学一看到实际结果和预期不一致就觉得这是风险,但是又说不出会带来的影响,以及这样的业务逻辑是否真的不合理,是否有解决方案。“风险”这个词变成了一个借口,测试同学可以不去评估不去思考这背后的逻辑,也不提出解决方案,上来就甩出一系列“风险”,这是对业务理解不够深入,没有主动思考的体现。
其次,明确功能的优先级和重要性。针对待测需求,心里要有一把称,明确哪些功能优先级高,哪些比较重要,哪些是这次可以忽略的。
在时间不充裕的情况下,我们可以从优先级和重要性入手,优先确保重要的功能和场景,再一步步往外蔓延,确保上线风险在可控范围。
最后,列出待测试checklist。因为形势的变化,我们一开始设计的测试用例可能不是这么合适,这时候需要及时调整测试计划和测试用例,在时间不充足的情况下,可以直接列简单的checklist,可以快速确认测试点即可。
结合前面分析的风险级别高的问题以及优先级和重要性高的功能,我们将这些梳理成可执行的checklist,然后一个个进行测试和验证。
总结
出现临时情况不可怕,甩锅和抱怨解决不了问题。作为职场人,我们遇事还是要理性一些,不要上来就焦虑发怒,而是要分析当前问题和矛盾,以及思考作为测试我们可以如何应对。
绵薄之力
最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走
这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助…….
相关文章
- 【原】YUI压缩与CSS media queries下的bug
- bug_ _Popwindow被魅族手机自带虚拟键挡住完美解决
- MySQL · BUG分析 · Rename table 死锁分析
- 谈Java集合类的toArray()的小bug
- hdoj-1289-A Bug's Life【种类并查集】
- [C++]佛祖保佑,永无bug。C++ BUG解决方案
- 小程序连续点击bug解决
- Java-idea-PMD源文件级别潜在bug查看
- 8年测试工程师 —— 如何尽量多的发现bug(缺陷)
- Iocomp .NET WinForm Bug Fix
- 【IDEA插件】这5款IDEA插件,堪称代码BUG检查神器!
- 和日期相关的代码和bug——一道力扣题中的小发现
- 为啥程序会有bug?