敏捷测试

 敏捷很容易被作为鼠目寸光地开发的借口。
在我的团队中，最优秀的程序员是最会沟通的人。或许我们对于“优秀”的定义不同。

优秀的定义是使别人解决他们曾认为他们不能解决的问题，也就是一个团队可以共同做的有多少。

XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。

在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。

 

在敏捷方法中，测试人员的价值又如何体现？

1、首先在需求讨论上，测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

2、在开发过程中，测试人员不仅扮演“用户代表”角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审（code review）， 将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

3、测试人员还是可以参与单元测试。即使单元测试由开发人员做，测试人员可以推进开发人员进行单元测，检查单元测试状态，如确保单元测试达到80%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。

4、即使在敏捷方法中，集成测试、端到端（end-to-end）测试、性能测试等是不可少的。因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块/组件），集成测试和端到端（end-to-end）测试显得更重要。测试人员在功能测试上工作量会降低，但在这些测试上发挥更大的作用。

5、随着迭代的不断深入，回归测试的工作量很大，这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本，这也是一种持续的努力，使回归测试自动化。测试人员对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

而且：
在敏捷方法中，我们也要采用敏捷测试，不要再写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点列出来。
在敏捷测试中，可能不需要测试用例，而是针对use case 或user story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。
所以：
敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试)
  理想情况下，测试人员具有很好的编程能力，可以和开发人员进行角色互换。在当前版本开发（/迭代周期）中担任测试人员角色，在下一个版本开发（/迭代周期）中担任开发人员角色，而开发人员则担任测试人员角色，让开发人员深刻地理解用户的需求角度来考虑系统功能的设计，这样会更好地保证产品的质量，沟通的障碍也会消除，开发的效率会有很大的提高。这也是对测试人员的一个挑战。
  敏捷测试也是一个持续测试的过程，而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。项目采用敏捷方法，要获得成功，项目组中每个人都有很强的质量意识，具有质量的主人翁精神，特别是开发人员，每时每刻提醒自己——“质量是构建出来的”，与客户或产品设计人员进行充分沟通，遵守高度一致的质量标准。

 

我总结一下：敏捷就是让测试人员变得像开发人员一项融入开发，开发人员搞得跟测试人员一样重视测试。总之就是大家都是一个team。