敏捷游戏项目测试策略(二)－摸着石头过河

书接上回，上次主要谈了谈敏捷游戏项目测试面临的挑战和困境，本篇我们结合一个项目实践来谈谈如何解决这些问题。

以笔者所在项目为例，在项目初期我们也遇到了上文所说的各种困境，后来我们做了很多努力和探索，终于让项目逐步走上正轨，基本规避了大部分问题，那么我们是怎么做的呢？

笔者总结了下，基本可以用下面的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。

三：定流程：

3.1，优化流程，并坚决执行。

不合适的流程一定要优化，还是说个项目真实实践流程改进的例子，之前项目任务不拆分，每周一大家开个会定下本周做什么就完事了，结果经常出现功能延期，版本无法定期或足量上线的情况。大家很郁闷，因为没法定量，很难确定到底是哪个环节出问题，等知道哪个环节出问题，再做调整时间上也来不及了。痛定思痛我们仔细分析讨论后，逐步把所有当周任务都拆分到每人每天工作量的细度，并每天下班前一起核对当天的完成量，这样我们能及时了解到版本进度，一旦出了问题，也可以及时协调资源来弥补。这个流程实施后，基本杜绝了版本延期的风险。

3.2，及时反馈，随时改进。

流程不是一成不变的，要根据实际工作情况及时调整改进。还是举个实际例子。我们的测试绩效考核内容变更过好几次。因为每个项目工作内容不大一样，而且由于我们分拆功能测试和平台测试，导致工作差异进一步扩大。所以我们前前后后根据实际情况调整了好几次绩效考核方案。最后调整到考核方案基本能跟实际工作内容相匹配。

四：常总结：

4.1，不在同一个地方失败2次。

我们经常会发现同一个bug会在不同的版本中出现，弄的大家挺没有面子。我们发现这个问题后，做了2个措施，让这种情况大大的降低了。一是我们每周组织一次测试部门与运营部门的事故核对会议，通过相互监督促进测试人员更加谨慎小心。二是我们开发了一套外网事故数据系统，将以往的各种外网事故数据都上传到数据系统中，让各个项目都能借鉴，尽量规避相同的问题再次出现。

4.2，沉淀并推广。

在1个项目出现的问题，很有可能继续在另一个项目出现。为了应对这种现象，我们把项目中积累的经验教训都总结成相关的流程文档，尽量将流程通用化，如果确认是对项目有利的，我们会强制推广到各个项目适用。比如我们的checklist制度，app评审制度，sdk测试流程，活动配置检查流程等等，目前我们正在努力做性能测试的标准流程制度。沉淀积累需要时间，不能寄希望于一揽子解决方案，最好的是从点滴做起，做好一点是一点，日积月累，必有成效。

以上说的是笔者亲身经历的项目，都是来源于一线的经验和实践，希望能对各位小伙伴有所帮助。

最后强调一点，各种调整改变，都需要项目整体来一起努力，单独靠测试个体很难改变，所以需要测试人员积极沟通，陈述利弊，争取整个项目的支持，才能做好。所以光知道改变的方法是没有用的，关键还是努力争取一切可以争取的力量，协调一切可以协调的资源，努力做好沟通，才能推动整个项目的不断前进。

当然，项目发展的每个阶段都会出现新的问题，需要我们持续的努力。加油，各位测试的兄弟！