冰冻三尺非一日之寒 － 王充
以笔者所在项目为例，在项目初期我们也遇到了上文所说的各种困境，后来我们做了很多努力和探索，终于让项目逐步走上正轨，基本规避了大部分问题，那么我们是怎么做的呢？
笔者总结了下，基本可以用下面的12字真言概括，即：做减法、改思想、定流程、常总结。
我们通过实际例子来详细描述下12字真言，以及我们通过这么做取得了哪些效果。
一：做减法。为什么做减法？作为测试本身来讲，做减法是痛苦的，意味着某些更稳妥或从前被验证过有效的测试流程要做改变，也意味着保证品质的难度增加。然而为了整体项目的进度我们不得不这么做。那么我们怎么做才能在做减法的同时做好品质保证呢？
1.1，抛弃不必要的流程：
1.1.1）砍掉回归测试的大部分内容。如果我们按照传统的方式做测试，我们至少要做详细的回归测试，而实际项目版本更新速度是1周更新1版，时间根本来不及，只能砍，但是怎么保证品质呢？在做减法的基础上做加法，更加细化版本上线前的checklist检查，基本做到类似回归的概念，但是时间会减少很多。砍多加少，整体上是做减法。
1.1.2）砍掉不必要的测试用例评审。用例评审继续做，但是只做重点功能的用例评审，非重点功能用例不再评审。
1.1.3）砍掉会议中的无效时间。会议需要谁谁参加，只讨论必要内容，非群体沟通私下进行。
1.2，分拆功能测试与非功能测试。
项目组测试只测试游戏功能本身，其他的类似sdk测试，性能测试等统一放到平台组去做，让专业的人做专业的事，提升效率。项目中的测试人员减少了，但是更加专注于版本功能本身，从而也有利于保证质量本身。
1.3，灵活的集中测试。
举个实际例子，比如app提交审核前的检查，放到项目里做可能会耗费较长时间才能做完，而且鉴于测试人员的经验，还可能会发生遗漏现象。我们的办法是临时抽调几个对app审核非常熟悉的人，大家坐在会议室里，快速的把检查点做完。即能保证质量也能提升效率。
二：改思想：思维不改变，则执行无效率。
2.1，拒绝等待。
2.1.1）以前经常遇到某项工作没开始是因为等别人的结果，这种理由经常让人无可奈何。我们怎么做的呢？在每日进度核对（这个流程我们后面会讲）上，我们详细的核对每项任务开始结束时间，如有有必须等上一项任务完成才能开始的情况出现，我们会安排新的任务来填充这段等待时间。以此来保证工作饱和度。
2.1.2）另一个层面，敏捷项目，测试是不能等开发都开发完毕打好包后再开始测试的，而是任何一个功能开发完毕，甚至一个功能中某个阶段开发完毕，我们立刻更新资源到本地，然后立刻开始测试，尽量保证测试与开发同步进行。
2.1.3）坚决不等，我们测试要催促开发按时或提前提交代码，让我们能尽早开始测试工作。
2.2，少抱怨，多思考。
这里不是说不能抱怨，在我们的团队中我们甚至鼓励相互吐槽，目的是让大家尽可能从多方面得到反馈，哪些地方做的不好要及时改进，我们这种抱怨可以说是正方向的激励方式，大家关注的不再是抱怨本身，而是工作出了问题，怎么能第一时间得到反馈，怎么能想办法把问题解决掉，从而以后不再范同样的错误。
2.3，随时沟通。
当然这一项也可以归并到拒绝等待里面，单拿出来说是笔者个人认为再敏捷项目，沟通变得比以往更重要。我们项目中会提倡随时沟通的概念，有问题不要发邮件，或者聊天软件留言，尽量找到责任人工位，随时当面沟通，提升沟通效率和信息准确性。最怕的就是大家坐的很近还要通过邮件你来我往的沟通，不仅浪费大量时间，还会再沟通过程中降低信息的准确性。
2.4，抛弃内网bug数量的概念。
笔者经历过很多公司，很多项目中的测试管理者非常重视内网bug提报的数量，如果时间充裕的话，我觉得没什么问题，但是再敏捷项目，这可能成为项目的一个阻力。我个人认为提报bug很重要，但是比数量则失去了其本身的意义。在敏捷项目由于各种条件限制，我们把指标更换为外网事故数量。以此来衡量测试对项目质量保证工作的好坏。注意此处外网事故指的是通过现有技术手段能够测出来而没有测出来的bug。
