敏捷宣言：个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。-www.agilemanifesto.org

什么是敏捷测试？

　　测试遵循敏捷宣言进行，把开发作为顾客看待。项目的测试采用敏捷方法论。

　　敏捷测试的原则与上下文驱动测试（Context-Driven Testing：www.context-driven-testing.com）的原则有交集，例如，上下文驱动测试的七大原则中的第三条：工作在一起的项目组成员是项目的上下文的最重要的组成部分。就与敏捷宣言中的“个体和交互比过程和工具更有价值”一样强调人的作用。

敏捷测试中测试人员扮演的角色

　　1、  测试是项目的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。

　　2、  测试为项目组提供信息，使得项目组基于可靠的信息作出正确的决定。

　　3、  “BUG”是让用户感觉烦恼的东西，测试人员不作出发布的决定。

　　4、  测试员不保证质量，整个项目组对质量负责。

　　5、  测试不是抓虫子的游戏，它的目的不是纠缠在错误中，而是帮助找到目标。

单元测试和可接受性测试

　　测试驱动开发，开发人员在写代码之前要先写单元测试，用于激发代码的编写、改进设计（降低耦合度，增加内聚）、支持重构。很多开源的测试工具支持单元测试（xUnit）。

　　用户故事是需要编码实现的功能特性的简短的描述。可接受性测试验证用户故事的完整性。理想的情况下，用户故事是在代码编写前就写完。

　　测试人员是否应该拥抱敏捷开发？

　　有些人说XP会导致差的质量并且是偷懒的借口。我认为XP是令人激动的，并将在行业中改进测试的实践。

　　参见《Testers Should Embrace Agile Programming 》

　　（http://www.io.com/~wazmo/papers/embrace_agile_programming.html）

敏捷测试实践

　　通过对话产生测试，谁来测试？客户往往太忙了，不可能参与测试。定义测试是很关键的活动，应该把开发人员和顾客代表包括进来，不要只是测试员自己做。

　　把用户故事转换成测试。测试提供的是目标和指南、及时的反馈、进度度量。测试应该用指定的格式出现，以便让用户或顾客能清楚明白，还要足够的明确，以便能被执行。

　　开发人员负责提供支持自动化测试的特性。大部分情况下，为产品添加测试接口，而尽量不用外部测试工具。

　　计划在每个迭代中探索产品，寻找bug、遗漏的特性和改进的机会。