随着移动游戏浪潮的到来，越来越多的游戏开发商主动或被动的选择了敏捷开发模式，这是大势所趋，顺应潮流不仅给整个项目带来了很大挑战，也给熟悉了传统的瀑布或慢迭代的测试人员带来了非常大的挑战。尤其是那些从端游项目转到手游项目的测试人员。这些挑战不仅仅来源于技能和操作层面，也来源于思路和思维层面。
敏捷项目的初衷是提升迭代效率，尽可能的缩短版本发布周期，然而很多敏捷项目却跌入了一个恶性循环的怪圈，即：开发周期缩短导致需求一开始就很难考虑周详，导致需求变化频繁，导致开发剩余时间减少，导致测试时间被动减少，导致返工增多，继续导致开发剩余时间继续减少。。。
这仅仅是纯工作层面，更可怕的是最终会影响项目每个成员的心理，在一个协调不好的项目大家很难开心工作，甚至会相互抱怨，相互推诿，积极性和主动性降低等，最终项目的效率反而更加低下，严重的可能导致项目人员流失。
这个恶性循环以前出现过，现在在某些团队也正在发生，将来也不会灭绝，而且很难被调整，从而导致了很多项目最终的失败。相信跟过多个不同项目的同学们会深有感触。
不仅是这些挑战，我们测试人员也有很多委屈。比如出了事故就责怪测试没测出来，项目进度拖了就怪测试拖时间等等。
上面说的是很多敏捷项目的通病和我们测试人员的委屈，作为项目重要组成部分的测试团队，我们来看看在敏捷项目中我们测试人员的的挑战点和委屈点在哪里。
首先我们通过2张图来对比下不同的游戏项目测试流程，如下：
测试团队的重心在于项目的品质保证，而敏捷团队的重心更偏重于快速迭代，这两者之间看似天然存在着不可调和的矛盾。因为要品质则意味着需要更多的时间，而时间恰恰是最难协调的资源。
我们来看一下快速迭代带给我们测试人员的挑战有那些？见下图
通过上图，我们可以把所有的矛盾和委屈推给时间这个冤大头，如何处理这些看似艰难的矛盾和挑战成了我们敏捷项目测试人员的一个难题，需要我们测试人员做大量的探索和努力，当然也需要整个团队的持续改进。然而真的是无法解决的么？有没有一种良好实践来解决这些问题呢？如何让我们测试人员挺直腰杆，不再委屈？笔者肯定地说是有方法的，具体如何解决，我们下回分解。
本次我们主要谈一下挑战有哪些及主要导致问题的因素，下次我们结合一个敏捷游戏项目的最佳实践重点谈谈如何应对这些挑战及我们测试应该采取哪些策略。
版权声明：本文出自 ervinzhang 的51Testing软件测试博客：http://www.51testing.com/?492258
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
