敏捷
反应快速灵敏。
在敏捷软件开发领域，更注重的以人为核心，迭代，循序渐进的开发方法。相比传统的开发方法，这种方法能更快速的开发，上线，反馈，调整、迭代。以敏捷的姿态去发展产品。
敏捷与传统开发的区别
有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色，一个是“老板”，另一个是“员工”，在 2 分钟内，“员工”需要在“老板”的完全指挥下，即“向前一步，向后一步，停，向左一步，向右一步”，完成 60步移动的任务。“员工”需要执行“老板”的每一个指令，不允许做出相违背的动作。“老板”则不参与行动，只发出指令指挥“员工”的活动。我们体验这个游戏 时，当场 60% 的参与者成功完成了任务，大致估计出我们的工作效率是50%*60%=30%。游戏后，参与者被问及对这种行为方式的感受时，无论是“员工”还是“老板”都表示非常不满。
接着，大家又做了另一组游戏。2 分钟内参与者被要求独立的、自主的完成 60 步移动任务，在这次游戏里，所有参与者任务相同，大家可以自行决定、并依据自己的判断随时调整其步伐方向，快慢。最后，我们发现所有参与者不但毫无折扣的 按时完成了任务，因而工作效率也达到 100%*100%=100%，而且所有人对于这种新的工作方式更是产生了极大的兴趣。
敏捷开发与传统开发的比较
通过上面有趣的两种游游戏的对比，以及价值表述的对比就折射出了传统开发与敏捷开发的方式的对比，其中的优劣不言而喻。
敏捷开发
敏捷宣言：
敏捷方法分类：
除了图例中的方法外还有 Crystal, Lean Software Development, Feature Driven Development, Xbreed, RUP 等等。
敏捷方法的共性：
虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：
* 拥抱变化
“唯一不变的就是变化”所以，需求的变动是必不可少的，每次的决定和需求的调整都是将产品开发推向更正确的方向。而在接受变化的同时，我们应该积极的反馈显示活动中暴露出来的可能的设计缺陷和错误。
* 客户的参与
最终使用者、内部使用者、客户代表、商业伙伴都可以是我们的客户。对于客户的参与更能使我们做出客户真正需要的产品。
* 较少的文档
传统开发的文档在敏捷中仍有大用，只是我们可以将原来的文档进行精简。在敏捷中文档不是最佳的沟通方式，更鼓励通畅的交通和沟通，而沟通的效率远高于文档。
* 最大化的生产力
敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通平台都是为了帮助 团队能够集中有限的精力处理。
* 测试驱动开发
是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
* 自动化冗余工作
将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。
* 民主的团队
敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。
敏捷测试
不是说敏捷测试么？这怎么看上去测试跟敏捷没一毛钱的关系。人家都敏捷了，还要测试做什？
在敏捷开发流程中，测试不再是瀑布试开发流程的一个环节，而是全程参与整个开发流程。通过各种方式来保证产品的质量，无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试驱动开发”，“行为驱动开发”，都离不开测试的支持。 当然，敏捷测试对测试人员提出了更高的要求，对测试人员来说也是新的挑战。
敏捷测试人员的定义
专业的测试人员，适应变化，与技术人员和业务人员展开良好的协作，并理解利用测试记录需求和驱动开发的思想。
敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试，他们希望了解客户在做什么，以此更好地理解客户的软件需求。
敏捷测试思想
对于一个敏捷团队而言，需要持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验，这需要大量的训练、学习、时间、试验和协同工作。
对于一个敏捷测试人员，他（她）会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自已的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。
基本要求就是敏捷测试人员和其它敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都应具有。敏捷测试人员帮助开发人员和客户团他解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效，哪些无效。
测试人员可能在测试领域拥有特殊的技能和经验，但一名优秀的测试人员并不惧怕参与一场设计讨论，提供有且于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的，乐于学习的、勇于不断生产业务价值的。
测试人员的十条法则
敏捷测试人员的十条法则：
- 提供持续反馈
- 为客户创造价值
- 进行面对面的沟通
- 勇气
- 简单化
- 持续改进
- 响应变化
- 自我组织
- 关注人
- 享受乐趣
提供持续反馈
既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位 。既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位 。
为客户创造价值
敏捷开发就是在较低的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。
进行面对面的沟通
一个团队如果沟通不好则难以协作。如今，许多团队分布于多个地理位置，沟通变得更加重要和富有挑战性。敏捷测试人员应该尽力促进沟通。这是把工作做好的关键因素。
勇气
勇气是极限编程的核心价值，类似测试自动化和持续集成的方式允许团队实践这种价值。 测试人员固守于自己的领域，不与其他业务相关者和技术团队进行任何讨论。虽然你找机会进入了协作的敏捷环境，可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。
当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时，通常你会产生恐惧感，并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成对每一个用户故事的测试任务？测试如何跟上开发的节奏？如何确定需要多少测试？又或者你是功能测试经理或者质量过程经理，但不清楚在敏捷团队中如何定位自己的角色，也没人知道答案。敏捷测试人员需要勇气找到这些问题的答案，但需要勇气的原因不仅限于此。
简单化
敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。而是说，当业务部门的需求比较复杂的时候，团队可能需要将方案退回给他们，更简单的解决方案也会产生同样的价值。
简单并不意味着容易。对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。
持续改进
想办法把工作做得更出色是敏捷测试人员应牢记的。
敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物，以验证是否值得长期采用。
学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能。
响应变化
响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定，所以他们会说：“我已经测试过了，任务完成了”。持续的需求变化是测试人员的噩梦。但是，作为一名敏捷测试人员，我们不得不拥抱变化。周三，我们可能期望启动故事A和B，下周五做故事C。但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。只要我们持续与客户交流，我们就能处理这些变化，因为我们与团队的其他成员保持同步。
自我组织
敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时，任何测试问题都会更容易解决。
当敏捷团队面对一个严重问题时，比如进度障碍或者构建失败，该问题将是所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定解决的办法和相关参与人员。
关注人
只有优秀的员工出色地工作，项目才会成功。敏捷价值和准则的宗旨是确保个人和团队成功。敏捷团队成员应该有安全感。不必担心因犯错受指责或者失去工作。敏捷团队成员互相尊重并认可个人成就。敏捷团队的所有人应该有机会提高和发展他们的技能。敏捷团队以可持续的步伐前进，使他们能够遵循严格的实践和保持崭新的视角。正如敏捷宣言所说，我们重视个人和合作超过过程和工具。
享受乐趣
在我们看来，测试人员的理想团队是：所有成员协作，从项目的开始一直到结束，利益相关者与开发团队共同工作，整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。
敏捷测试人员的工作特别令人满意，因为我们的角度和技能对团队产生了真正的价值。
敏捷测试人员应该做什么？
看了这么多，你一定问：
测试人员在敏捷团队中应该具备什么技能？
测试人员在敏捷团队中从事哪些具体的工作？
在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人认为从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述。
回答的很含糊，个人认为敏捷测试人员应该具备的两个主面。
首先，接纳并理解敏捷的核心价值观（沟通，简单，反馈，勇气，尊重、学习、分享）。
其次，测试人员应该具备测试基本技能，当然，可以擅长某个领域，如，探索性测试、单元测试。善于学习与分享，以学习的方式不断的提高自身去适应团队的需求。
我想说的是，不管是从传统开发模式转到敏捷测试，还是重新组建一个敏捷的测试团队。并不是一蹴而就的事儿，需要长期的学习、摸索与改进。当然，前提是以敏捷的价值观为指导思想。
-------------------------------------------------------------
本文引用资料：
段念《什么是敏捷软件测试》
《IBM敏捷测试的最佳实践》
《敏捷软件测试：测试人员与敏捷团队的实践指南》