stcupwar 发表于 2016-11-24 14:53:00

【新手必看】测试如何在敏捷团队中工作?

临近年末,各家公司都进入了紧张的年前项目冲刺阶段,我们也不例外。每天开完早会,就听大家在抱怨任务太多做不完、一个月都没正常过周末了云云。

据开发部门的同事说,他们的任务列表的长度都快赶上老婆双十一的购物清单了,而作为与开发组联系最紧密的测试组,我们的处境也好不到哪去,毕竟用的都是一款协作工具。

为了提高测试与开发的协作效率,个人在尝试方法过程中也总结了几条小技巧,在这里和大家分享一下,欢迎互相探讨。

如何用敏捷方法做测试?

敏捷的核心就是个“快”字:快速开发,快速推出,快速验证产品方向。说白了就是管理每个小目标,保证他们能够按时完成。

想要运用敏捷方法,要注意几点:
1、开发做完一个小功能马上开始测试,减少等待时间。2、测试的工作量更加分散,不会出现一段时间无事可做,一段时间忙的要死的情况。
3、每次的bug都是针对刚刚开发完的功能,开发处理起来会更得心应手,减少沟通成本。

在与同事沟通中,我还了解到,将bug加入开发计划会大大影响他们的目标完成进度,往往问题刚整理出一些思路,就因为某些bug需要处理而被迫中断了。

所以很多时候,直到deadline临近,目标中还会存留大量任务。如果测试一味地只管提交bug,而不考虑开发的工作习惯和目标的可执行性,就会导致效率大大降低。


*内容截图自teamin演示案例,结构略有修改,下同*

解决这个问题,需要将bug单独管理,同时做到合理分配,有节制,分缓急。

比较好的做法是,测试根据当前的开发计划设置自己的计划,将所有bug按紧急、重要、一般3种优先级来划分(分几级不重要,重要的是如何处理分级不同的bug),优先挑选紧急bug放入当前目标,重要bug根据当前进展情况适量分配,一般bug可以暂时不考虑。

另外,bug最好能建立单独的项目来管理,保证开发的任务集中度,避免产生过多冗余信息(属于当前版本却优先度不高的bug)。


项目、目标、标签,三位一体

举个不恰当的例子,测试与开发的配合就像父母喂孩子一样,不能等到孩子饿了才给吃的,这样容易一次喂太多,引起消化不良;也不能什么都给孩子喂,要注意合理配餐,否则营养失衡影响健康发育。回头心疼的不还是你这个做父母的吗?(哎!好像哪里不对……)

计划经常需要修改,测试如何应对?

计划变更频繁可以说是敏捷开发的另一大特点。上文提到了将bug单独管理,并将筛选后的bug加入计划,那么这种单独管理bug的方式就可以解决计划频繁变更的问题吗?

显然不能,因为bug最终还是要加入计划,计划出现变更,之前分配好的bug也会随之发生变化,这样之前设定的测试目标岂不乱套了吗?而且想必大家也会有疑问,我分配到开发计划中的bug,相当于从测试项目中移走了,那么修改后我如何得知,又如何统一审核呢?

简单来说,我需要任务支持跨项目协同,这样可以将同一个任务分配给不同的项目,达到测试与开发既各自独立、又相互联动的效果。这其实比较难实现,好在我用的协作工具支持我这样做,具体怎么做我不太好描述,直接上图吧:


跨项目协同,任务状态共享

这样一来,我在测试项目中设置的目标计划,不会随着开发计划的变更而变化,计划的调整都是自主和可预期的,另一方面,也能解决任务状态同步和后期审核的问题。

如何编写测试用例?

计划开始阶段没有测试工作,主要就是做测试用例了。我想这也是不少测试小伙伴的心头大患。测试用例结构复杂,分支众多,很难做的很详尽,一开始更是不知道从何写起。

到目前为止,我还没有找到一款非常合适的管理工具能够比excel做的更好,管理工具即使能够自定义功能,也很难达到excel的灵活性。与其在软件中记录分支,我宁愿将需要参考的相关任务导出成excel,然后自己添加情况分支,做优化修改。


导出任务列表,便于用excel编写用例

我一般会在开发前期就将产品的整体计划导出,作为总的测试用例大纲;再将开发当前正在做的计划导出,作为版本测试的用例大纲。

经常写测试用例的测试小伙伴可能都深有体会,用例最头疼就是整理结构大纲,而产品的整体计划本身就是一个结构性很强的需求大纲,相当于一个全部功能点的索引目录。

我们只要导出,稍作修改和补充,用例的完成度就会相当高。而且这样做还省去了与产品、开发一条条对接沟通的麻烦,减少了大量的沟通成本。

这种看似“投机取巧”的方法会让测试的用例编写工作事半功倍,效率大大提升。

Miss_love 发表于 2016-11-24 16:21:21

支持分享
页: [1]
查看完整版本: 【新手必看】测试如何在敏捷团队中工作?