资讯专栏INFORMATION COLUMN

测试如何在敏捷团队中工作?

taowen / 698人阅读

摘要:测试的工作量更加分散,不会出现一段时间无事可做,一段时间忙的要死的情况。如果测试一味地只管提交,而不考虑开发的工作习惯和目标的可执行性,就会导致效率大大降低。这种看似投机取巧的方法会让测试的用例编写工作事半功倍,效率大大提升。

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

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

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

如何用敏捷方法做测试?

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

想要运用敏捷方法,要注意几点:

开发做完一个小功能马上开始测试,减少等待时间。
测试的工作量更加分散,不会出现一段时间无事可做,一段时间忙的要死的情况。
每次的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编写用例

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

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

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

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

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/8737.html

相关文章

  • 怎样构建测试自动化框架?你得记住以下三个编码实践!

    摘要:为了构建可伸缩的测试自动化框架,需要记住以下三个最重要的干净编码实践。因此,组织期望其或测试自动化架构师设计和开发健壮,可维护的智能测试自动化框架。包括适当的文档在测试自动化框架开发项目中工作的程序员不太可能独自编写代码。 ...

    Jason 评论0 收藏0
  • 企业成功过渡到云计算需要彻底改革的IT部门

    摘要:于年获得的职位,并发现了一个需要彻底改革的部门。此外,该报告还将云计算确定为了最需要专业开发的领域之一。为了能够成功过渡到云,首席信息官们正在重新组建他们的IT团队,使其变得敏捷、跨职能,并且拥有新的技能、角色和高度适应性的思维方式。 Paul Ryan于2017年获得OpenX的CTO职位,并发现了一个需要彻底改革的IT部门。 OpenX,一家制作程序化广告平台的技术公司,服务...

    HelKyle 评论0 收藏0
  • 可见性是DeVOPS和混合云的关键

    摘要:近年来,云计算无疑成为企业开展业务的关键组成部分,特别是当企业考虑数字转型的竞争时。其次,整体可见性和态势感知水平基于遥测和与所有职能团队的整个组织相关的。尤其是数字转换和云计算,是创新和更广泛业务转型的组成部分。近年来,云计算无疑成为企业开展业务的关键组成部分,特别是当企业考虑数字转型的竞争时。在全球范围内,企业正在将他们的应用程序和服务转移到云端,从而获得更低的资本性支出和运营支出的好处...

    kid143 评论0 收藏0
  • 转向微服务的八条建议

    摘要:坎贝尔说我们已经看到,随着团队采用微服务,从提交到制作的周期时间显著缩短。转向微服务代表着一场大变革,各个组织需要做好应对这种重大转变的准备。表示,企业还应考虑根据业务优先级为每个微服务的性能和可靠性定义服务水平协议。如今新应用程序的开发都与交付速度有关。向敏捷环境的大规模转移已经持续了数年,这促使人们有一种轻松快速地部署软件的意识。微服务是面向服务的体系结构(SOA)的一种变体,它将应用程...

    since1986 评论0 收藏0
  • 什么是云原生?

    摘要:可更新云原生应用程序始终是的,云原生应用始终可用。弹性云原生应用程序通过在峰值期间增加的资源来利用云的弹性。多租户云原生应用程序在虚拟化环境中工作,并与其他应用程序共享资源没有问题。云原生应用程序更加模块化,许多功能分解为微服务。云原生这个词被大量引用,尤其是云服务商。不仅如此,云原生甚至还有自己的基金会:由Linux基金会于2015年推出的云原生应用基金会(CNCF)。 云原生定义 ...

    Aomine 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<