测试如何在敏捷团队中工做？

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

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

为了提升测试与开发的协做效率，我的在尝试方法过程当中也总结了几条小技巧，在这里和你们分享一下，欢迎互相探讨。

如何用敏捷方法作测试？

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

想要运用敏捷方法，要注意几点：

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

我通常会在开发前期就将产品的总体计划导出，做为总的测试用例大纲；再将开发当前正在作的计划导出，做为版本测试的用例大纲。

常常写测试用例的测试小伙伴可能都深有体会，用例最头疼就是整理结构大纲，而产品的总体计划自己就是一个结构性很强的需求大纲，至关于一个所有功能点的索引目录。

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

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