小企业如何最大限度提高测试质量?

Posted on Posted in TestDoc

众所周知,小企业肯定人数不会多,很多能精简则精简。甚至很多小企业都没有测试人员,当我们有幸加入到一个不是很大的企业的测试部门,如何能更好的进行测试呢?

现在敏捷开发被炒的很热,其实,我觉得现在还没有一个完全正确的工作流程能去阐述清楚敏捷开发,基本都是每家小企业拿着个文档不全的理去美化自己是敏捷开发,1000个企业就有1000个敏捷开发流程。敏捷开发里是弱化了文档的重要性,更着重讯息的及时沟通,需求变更也平常。所以,敏捷开发里的每一环的人员自身能力都要很靠谱。而对于测试人员的挑战与压力无非是巨大的。因为没有统一的文档,我们要时时刻刻关注所有聊天群组、站立会议、邮件等探讨出的新需求,漏掉哪一个,就彻底漏掉了,没有根源可寻。但是一出现问题,你没有测到,某某这时就会站出来说,我明明在之前说过,说没说过没人知道,因为你不是对着测试说的,我们已经尽力去搜寻散落的需求,但是这种遗漏还是会存在,发生这种情况总会比较尴尬。

  但是如何能避免呢?

你需要一个记事本,新版本的所有需求,反正你知道的,无论何种途径,立马同步更新到你的记事本里,开发过程中的新增需求、修改的需求,删减的需求,都及时同步,这样就会最大化保证需求的同步,好记性不如烂笔头,这样在最后验收的时候才能确保万无一失。记事本可以考虑印象笔记、onenote,都还不错。

需求已经尽量得到了同步,接下来如何去进行高质量、高效的测试呢?

从高效的角度来说,敏捷开发完全可以摒弃测试用例。那种详细的、繁杂的描述也是就是耗费时间,没等你写完,就已经到了开测的时间。这时候的测试用例基本成了鸡肋,用也用不上。而且慢慢看测试用例的时间已经够我测完一个需求点了。但是我们又不能什么都不写,那我们和那些不懂测试,拿到手就开始随便点点点的人又有何不同?不写测试用例是节约了时间,但是如何保证质量呢?其实我们可以根据现有的需求列出checklist,这样即节约了时间成本,又给我们真正测试时提供了测试思维的提醒,不至于漏测一些常规路径,从而可以保证质量。

也许其他人会有更好的想法,我目前是这样安排的:


解释:

1、需求编号:有些录入到禅道或者excel中的需求是有编号的,为了方便我们查看,可以写出编号;有些是临时加的,我们可以直接写出需求点;另外如果有删减的,可以直接添加删除线。

2、checklist:即是需要测试的检查点,对应的A、B、C其实是测试人员。checklist由C写出后,给与A一些参考,A可继续完善补充checklist再给B参考,B测试过程中也可继续完善和补充checklist,这样最终返回到C手中的checklist已经丰富了好多。

3、系统测试:系统测试其实是很重要的一个缓解,需要测试好几轮,确保bug收敛到最低,然后交给B去交叉。

4、交叉测试:交给B交叉是为了发散出更多的路径,毕竟每个人看东西的角度都是不一样的,这样能更大限度的去保证质量。

5、验收测试:从写checklist到现在,C其实一直没有参与到测试,而这时,bug基本已经没有,C根据补充完善后的checklist进行最后的验收。

6、常规测试:这是我自己分化的功能模块,每个测试人员都有自己负责的模块功能。这样没有新增需求的模块、线上的应用、反馈的问题,都能对应到具体模块负责人,比如首页就是A一直负责的,所以最终新增需求都测试结束后,首页整个模块都需要A最后再去验收。

7、α测试:除去参与此需求从产生到结束的人员,找一些公司其他人员,充当用户,给与15分钟的快速体验,测试只需在一旁记录下体验期间提的所有建议就可以。这些建议也许不是bug,仅仅是操作上的不爽,这些也应该记录,之后汇总、讨论,哪些是必要解决,哪些是可以延期处理的,哪些是可以忽略的。

8、β测试:不一定每次的版本都需要执行,可以在重大需求,或者发布有风险的前提下实行。增加一些灰度测试,取一些真实用户去体验,及时收集用户的反馈,并可根据第三方查看日志,是否有崩溃等问题出现。

 

表格解释完了之后,明眼人都能看出,这样一层层测试下来,质量绝对是有保障的,而且能利用的资源基本都被高效利用了,已经实现了利益的最大化。针对于小型企业、测试部门人数不足的情况,我目前只能想到这样去安排工作,如果我之后发现有更好的工作方式,会及时更新的。

希望对你有作用。

发表评论

电子邮件地址不会被公开。 必填项已用*标注