/ QA

测试流程: 新手入行对测试流程的实战理解

对于测试入手

刚开始测,面临问题有三个。测试范围,优先级,业务操作不熟。

对于业务熟练,只能自己勤快,多操作产品。熟悉是很快的,但是面对陌生枯燥的东西,最难的不是脑子够不够用的问题,而是要先克服瞌睡,提高自己的兴趣和专注度。一周后你感觉已经很熟悉这个产品了,然而随后的几周里,仍会陆续发现一些你遗漏的地方……

测试优先级是容易忽略的问题。假如给你2天时间包括学习需求,编写用例,测试执行,bug报告,bug追踪,类似这样时间不够的情况很常见。那么你就需要考虑到验收时再去修复严重bug的风险,以及开发在等待bug去修复的闲暇。他们不让你闲着,你也尽量不要让他们闲着,自然就要优先测复杂的核心的改动,尽量测试与修复更高效地协作,提高团队效率,缩短周期。时间就是金钱,就是你的工资价值。

为什么我要倒着来说这三个问题,把范围放在最后呢。因为随着测试任务一个一个完成,你对测试的范围理解会越来越真实。个人觉得它是比较考验测试水平的,如果没做好它,最终测试和开发整个团队都会倒在产品验收前,如果产品验收再漏过,最后直接后果就是公司的用户损失。而测试范围,又需要上面两个的支撑,熟悉了业务,知道了轻重缓急,这时候你对需求文档转化为测试用例,才能越来越有把握。测试范围粗看就是需求的模块和功能参数逻辑要求,细看了还要分需求提到的,需求没提到但隐含的要求,以及需求矛盾,需要二次沟通,才能确定下来的预期结果。

别漏了设计稿的测试范围,这种完全脱离需求文档的玩意,有时抠得很细,有时还有临时决定的变更。到你测试时,千万不要马虎大意,以为对比是很简单的事,它涉及的页面模板,列表样式,按钮,字体,颜色,图文排版,逻辑判断对应的样式变化……测试工作量可大可小。

……

当然,大多数测试新手不需要这么谨慎周全,因为你还有测试主管帮你把关。实际工作时,对于测试团队只有一个人的情况是很少见的。

不巧,我正是。

对于测试流程

确定测试范围,确定了优先级,也知道了产品的大致功能和业务,如果你这时开始点点点,那是砍瓜切菜,势如破竹,立马提交测试报告,开发总监看完你的报告,他此刻的内心是惆怅的,因为bug太少了,不正常。

这就要涉及到测试流程了。流程的存在是为了弥补大脑的缺陷,比如靠记忆,靠一时灵感,靠反应,那都是不靠谱的,今天赢了,明天输了,在竞争如此激烈的今天,有几家公司输得起。甚至今天还风光,下个月就一落千丈,第二年销声匿迹也不稀奇。基于这种认知,才需要更科学的流程去做产品设计,产品开发,产品运营,产品客服,为了多对少错。

很多抽象的概念,就像测试流程这几个字一样,在你真正操作起来时,就会更深刻地理解它。乖乖地去写测试范围,写测试策略,写测试用例,编写bug报告,bug回归跟踪,每个步骤都是重要的,只要有一个短板,所有努力白费。

如果准备工作都到位了,bug为什么还是这么少,就需要考虑自己的测试用例设计是不是对异常考虑的不够充分,测试技术是否过浅,没能爆出bug来。

测试设计与测试技术,其中的细节这次就没法展开了,因为我还需要更多的成长,才能写出全面的看法。再说说bug。

bug报告有很多种提法,一句话,一张图,多句话,多张图,步骤描述,客户端参数,版本描述,从简单到详尽不一而足。如果项目给的时间非常充裕,你可以像绣花一样,去提交每一个报告。大家也可以有心情去欣赏精美的文档。但实际情况是,时间都是缺的。

那么你如何改进你的bug提交呢?有一个很有效的自我改进的方法,就是在开发看到这个bug后,通过他需要跟你再次交流的次数和精力,来判断你提交bug的水平。开发性格和思维不尽相同,有的人爱看逻辑步骤描述,有的人不爱看字,有的必须看到截图和涂鸦,众口难调,需要你去适配改进。

当然也有的开发压根不看bug描述,接到bug直接喊你来演示。即使你的bug内容和备注都写得很清楚,即使你现在已经在测别的东西。这里又要分情况,如果是在公司多年的开发,很可能他意识你的bug定位错了,才会喊你去说明白,如果是新来的开发,要么怕理解错,要么他之前的工作交流方式的旧习惯所致。需要你去体味,融入团队,收敛性子和脾气,寻求一种更务实的方法,大家一起去解决这个bug。

至于,团队中,谁先让步,这根本不重要,别纠结这个问题。

有时候,一个任务,你测了几天,发现bug的原因是需求改了,也没人通知你,测到时一沟通你才知道,这也是很正常的事。你也只好表示知道,默默去调整测试。