敏捷测试的挑战 软件测试
我们从上下文驱动测试的七大原则(www.context-driven-testing.com)可以看出，上下文驱动测试倾向于快速的反馈和适应变化的环境。所以上下文驱动测试的很多原则和做法可以应用到敏捷开发的软件测试中来。
什么是敏捷开发?
敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。迭代包括需求的开发和测试，典型的迭代周期是2周。目标随着从上一次的迭代中学到的东西、反馈以及商业机会而调整。
在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。定义好接受标准，开发直到单元测试和接受测试通过才算完成。
敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。
在敏捷开发中不存在回退，讲究持续地集成，单元测试(通常使用测试驱动的开发方式)，持续地进行回归测试。
为什么以前的开发模式不再适用?
以前的开发模式要求有详细的测试计划，但是缺乏足够的时间来写，而且测试计划受很多因素的影响经常改变。
以前的开发过程会专门留出一个阶段来测试，但是你不能定义进入和退出的标准，测试阶段会随之而过。
以前的开发模式强调变更控制，但是现在的软件需求变更非常频繁，变更成了家常便饭。
以前的开发模式要求测试要对软件做出权威的判断，但是测试很难做出权威的关于软件正确性的判断。
测试的作用
有价值的东西有么提供产品，要么提供服务。那么测试提供什么产品或服务呢?有人认为测试提供调试通过的、经过测试的软件。这是错误的回答。测试不提供产品，测试提供信息，关于开发过程中的软件的状态的信息，以便基于这些信息做出决定。
敏捷测试的挑战之一：测试员是否不再需要了?
既然有开发人员做单元测试了，我们还需要测试员吗?有些项目团队采用了敏捷开发方式后把测试员都给解雇了，然后过了不久他们就后悔了。
测试可以是除QA或测试员外的人来做，例如业务分析员，有些项目团队让开发人员来做接受性测试。
但是有专门的测试员带来两个好处：
1、 专注于用户使用而不是软件的技术实现
2、 专注于发现软件的错误而不是证明完整性
敏捷测试的挑战之二：测试不完整的软件
文章来源于领测软件测试网 https://www.ltesting.net/
