一说起质量保证,一般情况下,第一时间被cue到的肯定是测试同学,然后紧接着就会有很多质量相关的问题抛来。比如项目时间很紧,卡时间点上线,质量能有效保证吗?能不能做一些自动化测试来提升测试效率?能不能快点测完上线?……等等。对于产品经理来说,最好是开发同学完成开发提测后,分分钟就能上线。我想这是测试开发岗位衍生的重要催化剂吧,当然这也是所有测试同学梦寐以求的事情!
这次主要分享下工作中遇到类似问题的感悟,抛砖引玉。
测试时间不够时的质量保证
作为测试同学,我们经常会遇到:哎,这次测试时间又不够了,咋办呢?心里默默地念了几遍,跟好朋友吐槽下,抱怨这个,埋怨那个,然后再无可奈何地加班来搞定测试任务。
但其实我们可以捋一下我们抱怨的事情,捋顺,然后一一解决掉。只是我们在抱怨的当时没有意识到:这些抱怨其实都是可以解决,让工作变得愉悦。在尝试解决或改进这个问题之前,不妨先来看看经常会遇到的时间不够的表现:
项目赶进度,留给测试的时间根本不够;
没有按时提测,根本来不及测;
突然加了需求,测试是最后被告知,导致根本没有预估这部分内容的工作量;
提交测试的内容远超出了需求评审时的内容;
突然接到测试需求,没有余量的测试时间可以安排。
我们在谈论测试时间不够时,有个隐含约束条件:对应需求的上线时间无法更改。若是上线时间可以随意调整的话,就不存在测试时间不够的问题了。
那么我们可以先思考下:
当我们已经使用科学的方法评估出来预留给测试的时间不够时,我们是否在第一时间同项目组以及测试组织内部反馈了这个问题。也许有同学会碎碎念,反馈有啥用呀,我都已经说了很多次了。这里所说反馈是指——有效反馈,而不是无效的抱怨。比如说,客观地陈述现在遇到了什么问题,尝试了哪些方法,都不起作用,期望能得到什么帮助或者资源。
1.1
测试时间不够之入门级
举个例子,之前遇到过这样的场景:
测试参加需求评审后,根据以往经验,本次的需求内容在预计时间内无法按时上线,或者即使按时上线了,但肯定存在质量风险。
我们的做法是:
首先我们做了测试组内的
需求review
输出需求bug,输出已确定需求的测试用例编写、测试执行的工作量,同时说明存在需求bug的内容工作量暂时无法评估。
接着产品、QA、开发根据测试输出的需求bug再次进行一次
需求沟通会议
明确这些需求bug的处理,并再次确认本次需要上线的需求内容和上线时间点。
经过本次的需求bug沟通会议后,我们“惊喜”地发现,在QA输出的需求bug中,很多细节其实产品并没有梳理清楚,经过新一轮的沟通确认后,去掉了这部分内容,但如果存在这些内容的话,测试的工作量会大幅度增加,而如果没有这些内容,在产品方预期时间上线则完全没有问题。于是顺利解决了这次的“测试时间不够”的问题。
这是比较理想地解决“测试时间不够”问题的场景,而作为测试人,经常遇到下面这种常见场景。
1.2
测试时间不够之通用级
经过再次的多职能需求沟通确认后,原定的所有内容都需要实现,并且仍然需要在原定时间上线。我们尝试的做法是:
测试组内对产品修复的需求bug,再次进行需求review并进行对应的
工作量评估
这时工作量评估的目的是:明确本次需求内容需要的总的测试工作量。
明确测试组内在开发提交测试之前的各项工作内容和对应的
排期
明确每个事项的输入输出,对应的时间节点(确认点)和负责人。
同时,需要跟产品和开发密切沟通,对提交测试内容提早进行
合理拆分
保证分批提交测试而不是留到最后一次性提交测试,减少开发和测试的空闲等待时间。
测试组织输出高质量的
冒烟测试用例
给开发进行自测。这些用例可能会带来意外的收获,开发可能会在开发过程中有意识地避免相关(卡流程)的bug。
目前,一般都可以使用上述场景也能顺利解决“项目赶进度,测试时间不够”的问题。
1.3
测试时间不够之提高级
有些时候,我们会遇到测试准备工作完成和开发提交测试之间有一定的空闲等待时间。这时平时储备的自动化技术就在这时可以用上,为测试后续的高效回归做充足的准备。
当然很容易遇到个人的自动化技术储备不够,或者测试同学自身无法识别 自动化的需求时,需要测试同学要建立起向组织求助的意识。
上述做法能顺利解决“测试时间不够”问题的关键是:
测试进行有效的测试需求分析,并进行有效的输出和测试安排。
测试和其他职能进行充分且有效的沟通,并达成可行且有效的“协议”。
测试需要对确认的各个事项在约定的时间点做有效确认,并且及时识别并提出可能存在的影响上线时间的风险。
当我们向组织申请资源的时候,很有可能组织当前是缺乏这样的资源,但不代表以后不会有这样的资源。如果我们不进行有效沟通,那么组织就很可能一直都不会有这样的资源。事实上,上面的3个关键点对我们测试同学的软硬实力提升也有一定的指导意义。
遇到提交测试内容远超需求评审时约定的内容时,我们可以先快速地跟产品负责人进行沟通,明确目前提交测试的超出需求的内容是否需要在当前版本上线。
大部分时候超出本次需求范畴的内容都不需要在当前版本完成。那么我们会执行:
要求开发去掉超出需求范畴的内容。
当开发再次提交测试后,需要同开发确认去掉超出本次需求范畴内容的方式。
检查最新的提交测试内容是否符合本次的需求内容。
但并不是每一次降临的都是幸运女神,偶尔也会出现因为各种各样的原因,临时增加测试需求。实践中有效的处理方式是:
接受产品团队偶尔出现的临时需求,并且快速响应处理。
在接受的同时,严肃且明确告知产品团队,在开发进行额外需求开发的同时,必须同时将额外需求的内容同步给测试。否则测试有权拒绝临时需求,拒绝是为了质量保证。
临时增加的额外需求测试也同样遵守相关测试流程和测试规范。
而没有按时提测的场景就更普遍了。临近提测节点,测试同学总是战战兢兢地关注推送消息,默默祈祷按时提测,但经常事与愿违。
那为什么没能按时提交测试呢?
测试是否能更早地知道对应的需求内容无法按时提测?如果能尽可能早地得到提交测试延迟的信息,对于质量保障是有益处的。或者我们可以将按时提交测试作为提交测试后质量标准的一部分,以此来解决提交测试延迟的问题。
另外在项目沟通初期,测试是否可以依据自身的项目经验、测试组织的经验以及对开发团队的了解,尽早地考虑、识别到这个风险,并且有意识地管理这个潜在风险?如果有,那么当这个风险出现前,我们必将有很多办法来消除这个风险,而不是等到它出现后,手忙脚乱。关于风险的管理,项目管理相关课程有更精彩的内容,可以适当地学习下。
质量保证过程中另一个不可忽略的场景,产品或者开发同学,总是会抱怨测试时间太长了,能不能再快点。那么如何能缩短下测试时间呢?
之前遇到这个情况后,我们通过调查,发现测试同学经常抱怨测试环境不可用,从而导致测试时间的延长。可是并不能说清楚测试环境到底有多不可用。
于是,我们请开发同学做了个测试环境服务使用的监控,发现测试环境在工作日的使用率大概只有50%左右。而主要原因是:测试环境的服务挂了,没人管!
接着,我们明确测试环境部署的责任人,明确部署规则:只能在午饭和晚饭时间部署,并且部署前需要告知相关干系人,部署后对应的开发需要检查自己刚刚部署上去的内容是否OK。确定执行这个规则之前,当然也需要跟整个团队,特别是团队的相关负责人进行有效沟通。
经过一段时间的实践后,测试环境的可用度有明显提升,最明显的表现是,测试同学对于这方面的抱怨明显减少了,但还是会有一些抱怨,比如新的环境部署后,有一些重要流程会跑不通。经过再次调研,我们发现,并不是所有的开发同学部署环境后,都会去主动去检查自己部署的内容是否OK。
于是,我们又想了个办法,测试环境自动化部署后,进行核心功能以及重要功能的自动化测试,如若存在无法跑通的问题,则同步发送消息给对应开发。但其实,私聊的效果并不是那么明显,发到项目组大群的效果会更好。
通过使用上图的工具,经过一系列测试环境治理后,测试环境不稳定带来的测试时间延长被有效地遏制了。不过偶尔还会出现测试环境异常的情况。还有几个feature可以使用。
测试环境服务一段时间内不可用,并且无人响应该问题时,自动重启的相关服务,如果服务器重启后,测试环境仍然有问题,那么就自动回滚到上个版本,直到测试环境可用。
提交质量不高时的质量保证
除了测试环境的问题,还有另外一个经常遇到的卡测试进度的问题:开发提交测试质量不高。
在刚提交测试的半天里,会出现很多主流程都走不通;或者是提交测试内容不完整,不符合预期的提交测试内容,导致测试同学总是在等待,或者跟着开发一起联调。但是呢,这段时间,已经习惯性地被认为是测试时间了。因为:提交测试了!于是给产品和开发印象就是:测试时间好长……
2.1
约定提测标准
我们首先做的是:跟团队制定明确提交测试标准。
取得产品团队同意,开发在提交测试前必须进行一定程度的自测。
一开始,我们按照这样的提交测试标准进行执行后,会经常遇到,离截止时间还有一两个小时时,团队群里会出现好几条预期提交测试内容延迟提交测试的消息,或者是,确实按时提交测试了,但提交测试内容的核心功能无法进行有效测试。我们进行一定的调研后,发现对于一些经验不足的开发:
他们并没有意识到延迟提交测试会带来什么后果,他们会认为我们遵守了约定的提交测试标准规范;
开发们往往不清楚需要进行哪些功能点的自测;
或者是他们觉得自测OK了,但是实际提交测试后,测试同学会发现还是存在影响测试进度的bug。
于是跟产品团队沟通后,我们将提交测试标准1调整成:
按时提交在需求分析阶段各职能约定好的内容,若无法按时提交约定好的内容,开发需要提早1天在产品团队群里@所有成员进行告知。
提交测试标准2调整成:
开发提交测试前必须完成由测试同学提供的冒烟测试用例执行,提交测试的内容不存在卡主流程的bug。
2.2
调整提测标准
两个提交测试标准调整后,又经过一段时间的实践,测试同学发现还是有些模块存在比较严重的卡测试进度的bug。此时我们去检查开发提测时输出的自测结果:
发现自测结果中并没有按照“测试想象的那样”输出内容,而且当提交测试内容较多时,并不是每一条提交测试内容都有明确的干系人去核对所有的开发自测输出。
接着,我们去访谈了相关未遵守自测标准的开发同学,他们认为需要自测的内容太多了,太占用他们的开发时间,对于后端开发来说,前端的自测内容对于他们来说是个门槛,而且有一定的学习成本。
整理提交测试标准执行结果和开发的反馈后,我们明确了每个提交测试内容的确认的责任人。
针对开发自测痛点,调整了冒烟测试用例:
将开发自测的冒烟用例拆分成:前端开发自测用例,后端开发自测用例。即对应开发只需要完成各自的冒烟用例自测,输出对应的测试结果即可。
测试同学尽可能将开发自测的冒烟用例执行时间控制在30分钟内。若执行时间超过30分钟,尽早同开发进行沟通,保证对应的自测的冒烟用例能被有效执行。
同时,我们更加明确提交测试标准中开发自测后需要输出的内容:
测试提供的所有冒烟测试用例执行结果,比如所有用例是否都被执行,以及是否测试通过;
输出测试未通过的说明,未通过的用例对应的功能点预期提测时间,以及相关问题是否影响主流程等。
至此,通过提交测试标准的有效实施落地,明显改变了“产品和开发眼中,测试时间好长”的观点,而且让团队养成了在预期提交测试的前一两天,总会有相关干系人在项目群里主动同开发确认,是否能按时提交测试的好习惯!
这里还有个小遗憾,测试输出冒烟测试用例给开发,开发提测时输出自测结果等这些内容,都是通过文档或者邮件往来进行输出确认,对于项目的整体效率打了一定的折扣。未来如果有机会,一定来弥补这个遗憾。
而另外一种提交测试质量不高的情况,虽然出现频率不高,但也经常打扰测试:开发修复bug的质量不高。
最常见的表现是:修复了一个bug,但冒出来好几个其他bug,于是bug数量无法收敛,客观地延长了测试执行的时间。
对于测试新手来说,这真的很烦恼,一方面是无法延迟的上线时间,另一方面是比较弱的bug修复质量。让测试新手无所适从。此时可以适当引用历史经验:
在测试日常输出的测试小结中明确提出这个情况,引起团队干系人注意,尽可能早地处理掉这个风险。
测试可以建议相关开发同学进行代码review干预。
那么经过以上有效的测试环境治理,开发提交测试标准制定实施,我们在测试执行阶段在遏制测试时间“被莫名”延长,同时已经默默地推动了开发必须完成一定程度自测才能进入提交测试的流程。通过一定的风险管理,推动了开发切分feature提测,而不是憋大招,一下子提交了一大堆待测试的内容。而这些当然可以有效地缩短一部分真正的测试时长。
而以上都需要基于:测试有明确的测试计划,并且需要让所有的干系人,也就是项目组所有成员都有明确的预期;测试要依据相关的风险进行测试,最大的风险得到最高效地测试,科学地分配时间,缩短bug反馈的时间弧;进行严格的bug管理,所有重要的bug都及时修复。更加重要的是,需要要有良好的沟通和汇报机制,每天都让团队成员清晰地知道,距离版本目标还有多远。
自身能力提升的质量保证
我们除了优雅地处理好影响质量保证的外部因素外,作为质量保证的主体,测试人员自身的素养则更加需要重视。
3.1
挑战
曾经遇到这样的挑战:每次产品上线后,必出线上bug,也就是线上质量堪忧。
我们发现线上bug的表现是这样的:
必须显示的内容,有时候显示正常,有时候显示NULL;
必须显示的内容,有时候显示正常,有时候会显示空;
必须显示的内容,居然没有在预计的时间点被正确显示;
显示的内容存在明显的逻辑问题。
联系客服