上周去参加了一个敏捷沙龙，感觉还不错，发现还是有必要细细的学习、研究下，以下是收藏的一篇短文，拿出来和朋友们一起分享。
敏捷方法在软件开发中受到青睐，特别是在互联网应用服务系统的开发中，越来越多的公司采用敏捷方法，包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别，但基本思想是一致的，如客户至上、拥抱变化、缩短迭代周期、自我组织等。在敏捷方法中，流程相对灵活，强调沟通，通过充分的沟通来及时解决问题，由于沟通充分，文档不是很重要，而且有可能不采用Word等独立的文件格式，而是采用Wiki、空间等web内容方式。在敏捷方法中，需求变化比较快、产品开发周期很短（一、两周），给软件测试带来很大的挑战！例如，功能测试的自动化实现就比较困难，没有足够时间开发自动化测试脚本，要花大量时间讨论产品特性，及时进行产品的验收测试。自动化测试，更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践，开发人员能发挥更大的作用，而测试人员难以很好地发挥作用。在敏捷方法中，开发人员的主导作用更明显，讨论需求、实现需求，再修改需求、再实现、再重构，不断完善产品，测试人员容易边缘化。甚至在Crystal方法中，可以不需要测试人员，开发人员能承担所有技术性的工作。
在敏捷方法中，测试人员的价值又如何体现？
- 首先在需求讨论上，测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。
- 在开发过程中，测试人员不仅扮演“用户代表”角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审（code review），将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。
- 测试人员还是可以参与单元测试。即使单元测试由开发人员做，测试人员可以推进开发人员进行单元测，检查单元测试状态，如确保单元测试达到80%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。
- 即使在敏捷方法中，集成测试、端到端（end-to-end）测试、性能测试等是不可少的。因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块/组件），集成测试和端到端（end-to-end）测试显得更重要。测试人员在功能测试上工作量会降低，但在这些测试上发挥更大的作用。
- 随着迭代的不断深入，回归测试的工作量很大，这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本，这也是一种持续的努力，使回归测试自动化。
- 测试人员对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。
而且：
- 在敏捷方法中，我们也要采用敏捷测试，不要再写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点列出来。
- 在敏捷测试中，可能不需要测试用例，而是针对use case 或user story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。
所以：
敏捷功能测试 = 新特性的手工测试（use case验证和探索性测试）+ 原有功能的自动化测试（回归测试）
理想情况下，测试人员具有很好的编程能力，可以和开发人员进行角色互换。在当前版本开发（/迭代周期）中担任测试人员角色，在下一个版本开发（/迭代周期）中担任开发人员角色，而开发人员则担任测试人员角色，让开发人员深刻地理解用户的需求角度来考虑系统功能的设计，这样会更好地保证产品的质量，沟通的障碍也会消除，开发的效率会有很大的提高。这也是对测试人员的一个挑战。
敏捷测试也是一个持续测试的过程，而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。项目采用敏捷方法，要获得成功，项目组中每个人都有很强的质量意识，具有质量的主人翁精神，特别是开发人员，每时每刻提醒自己——“质量是构建出来的”，与客户或产品设计人员进行充分沟通，遵守高度一致的质量标准。
目前敏捷项目管理对人的要求还是很高的，请量力、适度而行。
