临近年末，各家公司都进入了紧张的年前项目冲刺阶段，我们也不例外。每天开完早会，就听大家在抱怨任务太多做不完、一个月都没正常过周末了云云。
据开发部门的同事说，他们的任务列表的长度都快赶上老婆双十一的购物清单了，而作为与开发组联系最紧密的测试组，我们的处境也好不到哪去，毕竟用的都是一款协作工具。
为了提高测试与开发的协作效率，个人在尝试方法过程中也总结了几条小技巧，在这里和大家分享一下，欢迎互相探讨。
如何用敏捷方法做测试？
敏捷的核心就是个“快”字：快速开发，快速推出，快速验证产品方向。说白了就是管理每个小目标，保证他们能够按时完成。
想要运用敏捷方法，要注意几点：
开发做完一个小功能马上开始测试，减少等待时间。
测试的工作量更加分散，不会出现一段时间无事可做，一段时间忙的要死的情况。
每次的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编写用例
我一般会在开发前期就将产品的整体计划导出，作为总的测试用例大纲；再将开发当前正在做的计划导出，作为版本测试的用例大纲。
经常写测试用例的测试小伙伴可能都深有体会，用例最头疼就是整理结构大纲，而产品的整体计划本身就是一个结构性很强的需求大纲，相当于一个全部功能点的索引目录。
我们只要导出，稍作修改和补充，用例的完成度就会相当高。而且这样做还省去了与产品、开发一条条对接沟通的麻烦，减少了大量的沟通成本。
这种看似“投机取巧”的方法会让测试的用例编写工作事半功倍，效率大大提升。
本文出自 “管理经验分享” 博客，请务必保留此出处http://menghumenghu.blog.51cto.com/12319119/1875734
原文地址：http://menghumenghu.blog.51cto.com/12319119/1875734
