严格的说，我对于传统测试没有太多经验。从06年进入游戏测试行业开始，我所在的团队就在尝试向敏捷方式的转变，成功敏捷后至今，已一年有余。而这近一年半的经历给了我很大的冲击，让我每天都对我的工作有新的认识和体会，这和以前在学院里获得的对于软件开发和软件测试的理解有很大的不同。

至少在我看来，传统的测试应该是——可以坐在我们测试部门专用的办公区内，等待产品策划的文档；拿到文档后着手准备用例，并看一下项目的计划；在程序员提交可用版本后对产品进行测试，然后将找到的bug提交bug管理系统；最后在产品计划发布之前，拿出几个还未修改的bug理直气壮地说，产品还未准备好……然而现在，我们不再和产品团队有空间距离，不再只是看文档写用例，不再只是提交bug，不再只是争论某个bug是否必须修改……敏捷的开发决定了我们必须以敏捷的测试来应对。

“沟通”成了最重要的技能之一

敏捷宣言里讲：个体和交互胜过过程和工具，客户合作胜过合同谈判。在内部需求上，开发人员就是我们的客户。而我在加入团队后所做的第一件事，就是搬位子到开发人员旁。当然，是被要求这么做的。一开始还有点不适应，毕竟我们被分离开了曾引以为豪的独立的测试团队，这和传统的观念是相悖的。不过在经历过几个测试阶段后，这么做的好处就体现了出来。

以往我们总要等到一个正式的版本，才可以开始测试，否则过多的介入会打乱开发计划。而现在，程序员就坐在我对面的隔间，他一抬头就说：“嘿，X功能做好了，我跑了一遍没问题，你来试试看？”结果我过去试了试，bug出来了。程序员的反应则是：“好，我马上改”。——这样一个bug从发现到修正，最多不超过半个小时。而以往，我要等到版本正式提交，再build好，再up好，发现bug后还要通过提交bug管理系统，等待系统发邮件给程序员。如果恰好程序员忘记开邮箱了，那就可能要更多的时间。

事实上这里面还有更多的细节。我相信大多数测试人员会和我有同样的经历，在发现并提交一个bug时，我们写了大量的文字来描述bug的环境，bug的重现步骤；程序员修正bug时，也自信满满的说，该bug已修正。但当你一复查时，却发现你所认识的那个bug还在，而程序员完全理解错了你所说的bug。而现在，你所需要做的，只是抬一下头，把问题说出来，直接和程序员进行沟通，让他能够准确的理解你的意思，甚至包括你对于该bug的分析。接下来一切就十分好办了。

此外，有时有些bug确实不是那么容易重现的，你需要和程序员配合操作，才能发现其中的蛛丝马迹。我们现在最常做的一种合作就是，由我来制造环境，按重现步骤操作，由程序员在另一端跟踪调试代码，一边沟通，一边进行，这样就能很准确的发现问题，并且能很快的得到修正。

仅仅是几句话的沟通，就能将一个bug在最短的时间内修正，这节省了多少时间？这皆得益于比以往更便捷的沟通。而我们所做的，不过是移动了一下位子，减少了我们之间的沟通成本，却大大的提高了开发效率——我已经记不清有多少bug在还没提交之前就被消灭掉了。但这也对我们测试提出了更高的要求，虽然之前的我们也很强调沟通能力，但现在由于需要更频繁的沟通，我们对沟通能力的提高也变得也越来越重要，成为了最重要的技能之一。

说到这里，其实我们已经能感受到，测试的角色定位已经变了。因为敏捷开发中，要对质量负责的是整个团队，这一目标就要求测试人员不再是一个独立的质量监督部门，而是要融入到整个团队中，成为开发中不可分割的一部分。

调整测试用例的粒度

敏捷宣言里还说，可以工作的软件胜过面面俱到的文档，响应变化胜过遵循计划。那么我们是不是可以都不要文档，不用写用例了呢。我想，如果你的项目是一个“Hello world多国语言版”，大可以如此。但如果是面对一个大型的，多人的，在线的，角色扮演游戏，还是算了吧。

曾经有位前辈跟我说，测试员最重要的技能就是写用例，通过用例来表达测试思想。我想，即使是到了敏捷时代，这个技能仍然是第一位的。只是，如果你的用例写得过于详细和复杂，那么在团队开始响应变化的时候，你就会措手不及了。

我就真的遇到过这种情况，某一个设计做到一半的时候，由于效果并不好，被要求进行修改。这时我的用例也要相应的进行修改——最怕这个了。如果这是一系列粒度很细的用例，动辄上千条，一旦改起来，费时又费力。但如果我的用例的粒度本来就并不是非常细，那我调整起来就快速多了。

至于粒度到什么程度才是合适的呢？那就要看个人的能力，是否强大到能随时调整一份复杂和详细的用例的程度。我个人并不推崇十分详细的用例，因为有些很细节的地方，也没有文档可以参考。而且我们测试的游戏，很多细节没有绝对的对与错之分。即使真的出现了一些有疑问的地方时，迅速的和程序员和策划进行沟通也比写一份更详细的用例要有效得多。要知道，我们的目标也应该和团队内所有的成员一样，是一款可以玩和好玩的游戏，而不是面面俱到的测试用例。

更多的测试方式

我看过不少介绍敏捷开发的文章，大都有这么说过：在进行敏捷开发中，快速的响应变化的前提，一定是对质量的保证。如果质量无法保证，那是无法对变化做出响应的。因此这要求程序员能更多的进行自测，包括白盒的，自动化的，测试驱动的。而站在测试人员的角度上，我们能做些什么呢？

因为对产品接触的更具体，我有了很多机会接触详细的程序设计，这使得我已经可以尝试直接阅读代码，并在此基础上进行测试用例的设计。行话说，这就是灰盒测试。灰盒测试带来的好处是，用例的设计可以比黑盒测试更简洁，而且随着你对程序框架的理解更加的深入，你对所测的产品会更有安全感。当然，传统的黑盒测试是不能抛弃的，因为很多bug都是在你所意料不到的情况下发生的。如何合理的分配灰盒测试和黑盒测试，这还需要在漫长的敏捷测试中慢慢体会。

除了简单的灰盒黑盒，测试人员尝试做一下白盒也是很有用处的。虽然程序员也做了这样的工作，但测试人员的测试思路会和程序员有所不同，得到的结果也许就会不一样。我就尝试过对核心代码进行白盒测试：包括代码的走查，对函数的独立测试，以及使用内存检测工具的检测，尽管最后还是没有查出bug。

最后别忘了自动化。由于产品会经常的响应变化——相信我，这事儿真的很轻易的就发生了，对于某些重要的系统的测试就会一次又一次的要重来。若系统简单些还好，若系统是比较复杂，或是比较核心的，如果还是用手动测试，那就会很让人头痛了。所以测试人员的自动化测试是很有必要的。为自己最容易自动化的系统写一个自动测试脚本，这样，随便他们怎么改动，我们都可以随时的进行回归测试了。

让更多的人参与测试

当测试人员已经不再是一个独立的测试部门时，需要进行测试的也就不只是测试人员了。程序员要自测，策划也要测试，甚至玩家也可以来测试。不同的人可以得到不同的结果，这样才能使我们对产品有全面的把握，才能时刻的知道产品下一步应该怎样“响应变化”。

程序员的自测可以减少程序上的bug。策划的测试可以使策划更清楚的看到目前游戏的现状，亲自体验自己设计的系统。而玩家的测试则可以给我们带来我们的最终用户的反馈，这是最有价值的信息。

我们现在就会经常邀请玩家来进行测试，让我们团队的所有人看到我们所做的游戏在玩家手里是怎么玩的，在玩家心里是怎么想的。这样不断的获得反馈信息，不断的改进后，相信产品会越来越受用户欢迎。最终的目标，就是一个可玩，好玩的游戏，每个人都是这样想的。

信任你的测试人员

虽然我是在谈论敏捷测试的体会，但无论你是测试，是策划，还是程序，或者制作人，甚至经理。你都可以而且应该多花点时间和你们的测试人员进行沟通。信任他们，因为他们比这个团队中的任何一个人都更了解产品的现状，他们也是产品面世之前的唯一的玩家。你可以私下找他们聊一聊产品，也可以偷偷的登陆bug管理系统看看现在的bug，甚至可以让他们协助你做一些非测试的工作（例如，产品演示，但不要占用他们的工作时间）。无论如何，他们一定会对你下一步的决策产生巨大的帮助的。

敏捷究竟是什么？说实话我没怎么仔细考虑过，只是就这样跟着一个敏捷的团队做了一年半的测试，把我们很多传统的测试理念都颠覆了，其实也只不过是在实践中不断的摸索着去改变自己的观念，改变工作方式。直到最近认真的看了看有关敏捷开发和敏捷测试方面的文献，才发现原来这一年半的经历和体会和书中所言是那么的相似，索性借此文和大家分享一下，欢迎指正。