[如需转载，请在转载时注明出处，并保证本文的完整性]
2012年11月3日下午，外面滂沱大雨使得气温骤然下降，在中国科技会展中心的一间会议室里，却被热烈的气氛包围着。嘉宾们和参会者的大脑高速运转产生的热量，在室内空调热力配合下，使得屋内显得很热。
我也在积极思考“敏捷”这两个字的含义，努力着在以往的测试实践和学习经验中寻找相关的体会。我希望通过向嘉宾提问更多的问题，来获取更多的知识。
我想起我头脑中也产生过一下几种对于敏捷测试的态度：
一、敏捷崇拜者，因为敏捷是新技术思想，所以和其他的新技术崇拜一样，当时年轻的心总想学习先进的新的知识来超越自我。
二、旁观者，经过对于敏捷的初浅认识和测试实践，发现敏捷并没有真正出现在我的实际工作中。而且，敏捷是一种应用在整个开发流程中的思想模式，那么只有在敏捷开发流程中的测试才可称之为“敏捷测试”。那么单独的“敏捷测试”应该是个伪命题了。而且我又适应了现在的工作，无法改变开发的流程，那么敏捷与我无关了？
三、敏捷反感者，当然这不是我自己的想法，但是我可以清楚得感觉到一些合作过的同事、同行是持这种态度。他们已经适应了现有的流程，对于敏捷的第一印象“敏捷就是没有详细的文档”，那怎么行，我们需求从哪里获取？测试用例描述不细致，我们测试执行参考什么？流程如何控制？其实我不清楚他们是害怕还是不愿去接受新鲜事物。
在参加这种技术交流时，常常感觉很耻于说出自己没有什么敏捷的经历。好像这就证明我能力有限，所经历的公司水平有限一样。我想无论是否是我低估了自己和自己所处的环境。还是要面对自己，才能够成长进步。
那么记忆中与敏捷沾边的工作，就是2009年在广联达公司的测试工作。印象最深的几点：
一、测试用例简化，以往的花了很长时间编写的测试用例，除了在第一轮测试时候会参考执行以外，作用非常有限，而且维护困难，每次例会讨论用例维护的方案总是不了了之。用例简化后，针对每个功能点列出简要的测试点在QC中，而不去写详细的用例。在每一轮的测试过程中都会去维护增加新的测试点。
二、测试提前，区别以往等待开发人员给出正式版本后再进行测试。而是，在得到需求的第一时刻，列出相应的测试点并发给开发人员确认，在与开发的沟通过程中得到对于需求的统一认识。然后在开发做完每一个新功能时，一个测试和一个开发坐在开发的工位上按照测试点，逐一在本机上验证。这样就不用从服务器上等到正式版本再测试了。
三、组织结构，拆散原来独立的测试部和开发部，根据产品、功能、地区版本划分，开发和测试以大概2：1的比例组成一个团队，当然由于需求人手紧张，所以一个需求人员会同时参与几个团队的工作。这样转变了原来开发与测试的对立局面。
四、每日站会，其实当时对于每天早上开会有些反感，也许是因为还没有真正体会到他的意义。
如果说敏捷中的测试必然都是需要自动化的，那么我们当时的自动化测试只是应用于冒烟测试和基本功能验证。无论是不是完全意义上的敏捷，还是有所收获的。记得后来曾经参加其他公司的面试，说起敏捷经历，我还会拿出此段经历来充数，汗！
那么回到现在的测试项目中，是否可以按照敏捷的思想来施行呢？会起到什么作用？解决什么问题？
从贺炘老师的PPT中看出，分析现在项目是否适合敏捷可以从以下几点来看：
1.项目特点；
那么我们的项目是离岸的测试项目，作为开发的客户是在美国，在项目特征上我们无法实现开发和测试结合的团队结构。而且由于时差问题，我们发出的问题只能在第二天得到答复，就无法实现敏捷所要求的及时反馈和沟通。
2.支持环境
正因为我们是独立的项目，在自主性上比较强，采取何种形式的测试流程和方式，不会太受制于人。另外我们的自动化回归测试一直在比较稳定得运行。以此来说，是属于比较适合的。
3.人员素质
我们的项目一直以来秉承着建立一个小而强的团队的原则，仅有的5个测试人员，从业务水平、代码能力、测试能力方面来说，都是能够独当一面的。
那么是无法做到敏捷了？敏捷的真谛是什么？是一定要符合几个关键字吗？还是一种解决问题的思路呢？
今天的会议中嘉宾们对于敏捷的意义探讨有几点：快速的价值交付、更加透明和有效的沟通、减少项目中的不必要的时间浪费。
回过头来，这不正是我们项目中存在的问题吗？
不得不说我们有很多人已经非常习惯于这个功利社会的游戏规则，也许一个人推动敏捷测试、推动探索测试、推动自动测试，真正目的是为了绩效、薪资和升迁。我们不能否认这是错的，但是如果解决了不了实际问题，反而由此产生的很多问题会给这些优秀的思想和技术脸上抹黑。还是在以后的项目中，踏踏实实学习，小心翼翼实践吧，共勉！
