三：定流程：
3.1，优化流程，并坚决执行。
不合适的流程一定要优化，还是说个项目真实实践流程改进的例子，之前项目任务不拆分，每周一大家开个会定下本周做什么就完事了，结果经常出现功能延期，版本无法定期或足量上线的情况。大家很郁闷，因为没法定量，很难确定到底是哪个环节出问题，等知道哪个环节出问题，再做调整时间上也来不及了。痛定思痛我们仔细分析讨论后，逐步把所有当周任务都拆分到每人每天工作量的细度，并每天下班前一起核对当天的完成量，这样我们能及时了解到版本进度，一旦出了问题，也可以及时协调资源来弥补。这个流程实施后，基本杜绝了版本延期的风险。
3.2，及时反馈，随时改进。
流程不是一成不变的，要根据实际工作情况及时调整改进。还是举个实际例子。我们的测试绩效考核内容变更过好几次。因为每个项目工作内容不大一样，而且由于我们分拆功能测试和平台测试，导致工作差异进一步扩大。所以我们前前后后根据实际情况调整了好几次绩效考核方案。最后调整到考核方案基本能跟实际工作内容相匹配。
四：常总结：
4.1，不在同一个地方失败2次。
我们经常会发现同一个bug会在不同的版本中出现，弄的大家挺没有面子。我们发现这个问题后，做了2个措施，让这种情况大大的降低了。一是我们每周组织一次测试部门与运营部门的事故核对会议，通过相互监督促进测试人员更加谨慎小心。二是我们开发了一套外网事故数据系统，将以往的各种外网事故数据都上传到数据系统中，让各个项目都能借鉴，尽量规避相同的问题再次出现。
4.2，沉淀并推广。
在1个项目出现的问题，很有可能继续在另一个项目出现。为了应对这种现象，我们把项目中积累的经验教训都总结成相关的流程文档，尽量将流程通用化，如果确认是对项目有利的，我们会强制推广到各个项目适用。比如我们的checklist制度，app评审制度，sdk测试流程，活动配置检查流程等等，目前我们正在努力做性能测试的标准流程制度。沉淀积累需要时间，不能寄希望于一揽子解决方案，最好的是从点滴做起，做好一点是一点，日积月累，必有成效。
以上说的是笔者亲身经历的项目，都是来源于一线的经验和实践，希望能对各位小伙伴有所帮助。
最后强调一点，各种调整改变，都需要项目整体来一起努力，单独靠测试个体很难改变，所以需要测试人员积极沟通，陈述利弊，争取整个项目的支持，才能做好。所以光知道改变的方法是没有用的，关键还是努力争取一切可以争取的力量，协调一切可以协调的资源，努力做好沟通，才能推动整个项目的不断前进。
当然，项目发展的每个阶段都会出现新的问题，需要我们持续的努力。加油，各位测试的兄弟！
版权声明：本文出自 ervinzhang 的51Testing软件测试博客：http://www.51testing.com/?492258
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关文章：
