| 敏捷团队里的每一个人都是一名测试人员，任何人都可能承担测试任务。如果这种说法是正确的话，那么对于一名敏捷测试人员来说有什么特别之处吗？如果我把自己看做是敏捷团队的测试人员，这到底意味着什么？敏捷测试人员相比传统团队里的测试人员需要不同的技能吗？有什么日常工作指南吗？
本章将讨论敏捷测试思维，看一看敏捷价值和准则如何指导测试，对测试人员如何为敏捷团队创造价值做一个概述。
1、敏捷测试人员的定义
我们这样定义敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。
谁是敏捷测试人员？她是驱动敏捷测试的团队成员。我们知道许多敏捷测试人员刚开始的时候在从事其他工作。开发人员可能会爱上测试而超越单元测试的范畴。习惯以敏捷方式工作的探索型测试人员也会被敏捷团队吸引。其他角色的专业人士，比如业务或者功能分析师，也可能具有同样的特质并做同样的工作。
技能很重要，但态度更值得关注。Janet总是说：“如果态度不好，那么技能则一无是处”。既然我们要为敏捷团队招募大量的测试人员，那么必须慎重考虑这一点，并与敏捷社区的其他朋友进行相关讨论。测试人员往往可以总览全局。他们更多时候是以客户的角度看待应用程序，这意味着他们一般以客户为中心。
2、敏捷测试思想
如何使一个团队变得“敏捷”？对我们而言，敏捷团队持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。
成功的项目总是因为优秀的人才完成了出色的工作。在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。
敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。
敏捷测试人员，可能包括其他拥有正确技能和思想的测试人员，都在不断想办法使团队能够更好地开发高质量的软件。对个人来说，这可能意味着需要出席本地用户组会议或者圆桌会议看看其他团队在做什么，同时寻找新的工具以帮助团队通过测试描述、执行和自动化用户需求。
基本要求就是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都应具有。敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。
创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。优秀的测试人员都有一种直觉和理解力：软件可能在何处失败？因为什么失败？
测试人员可能在测试领域拥有特殊的技能和经验，但是一名优秀的测试人员并不惧怕参与一场设计讨论，提供有助于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。
敏捷团队里的每一个人都是一名测试人员，任何人都可能承担测试任务。如果这种说法是正确的话，那么对于一名敏捷测试人员来说有什么特别之处吗？如果我把自己看做是敏捷团队的测试人员，这到底意味着什么？敏捷测试人员相比传统团队里的测试人员需要不同的技能吗？有什么日常工作指南吗？
本章将讨论敏捷测试思维，看一看敏捷价值和准则如何指导测试，对测试人员如何为敏捷团队创造价值做一个概述。
（1）敏捷测试人员的定义
我们这样定义敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。
谁是敏捷测试人员？她是驱动敏捷测试的团队成员。我们知道许多敏捷测试人员刚开始的时候在从事其他工作。开发人员可能会爱上测试而超越单元测试的范畴。习惯以敏捷方式工作的探索型测试人员也会被敏捷团队吸引。其他角色的专业人士，比如业务或者功能分析师，也可能具有同样的特质并做同样的工作。
技能很重要，但态度更值得关注。Janet总是说：“如果态度不好，那么技能则一无是处”。既然我们要为敏捷团队招募大量的测试人员，那么必须慎重考虑这一点，并与敏捷社区的其他朋友进行相关讨论。测试人员往往可以总览全局。他们更多时候是以客户的角度看待应用程序，这意味着他们一般以客户为中心。
（2）敏捷测试思想
如何使一个团队变得“敏捷”？对我们而言，敏捷团队持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。
成功的项目总是因为优秀的人才完成了出色的工作。在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。
敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。
敏捷测试人员，可能包括其他拥有正确技能和思想的测试人员，都在不断想办法使团队能够更好地开发高质量的软件。对个人来说，这可能意味着需要出席本地用户组会议或者圆桌会议看看其他团队在做什么，同时寻找新的工具以帮助团队通过测试描述、执行和自动化用户需求。
基本要求就是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都应具有。敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。
创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。优秀的测试人员都有一种直觉和理解力：软件可能在何处失败？因为什么失败？
测试人员可能在测试领域拥有特殊的技能和经验，但是一名优秀的测试人员并不惧怕参与一场设计讨论，提供有助于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。
（3）进行面对面的沟通
一个团队如果沟通不好则难以协作。如今，许多团队分布于多个地理位置，沟通变得更加重要和富有挑战性。敏捷测试人员应该尽力促进沟通。这是把工作做好的关键因素。
Janet的故事
我曾经在一个团队工作，当时开发人员只与产品负责人交流，而把测试人员排除在外。他们随后才寻求了一些改变。开发人员不与测试人员坐在一起讨论的部分原因在于制度问题。另一个原因是历史问题。测试团队是一个新队伍，产品负责人已经习惯了直接联系开发人员。
我在团队里提出了这个问题，大家建立了一个规则。我们发现“三方协作的力量”获得了巨大成功。这意味着所有关于一项功能的讨论都需要开发人员、测试人员和产品负责人的参与。每一个人都有责任确保“三方协作”。如果有人发现另外两个人在交谈，他有权利加入。很快这变成了惯例，再也没有人想把测试人员置于讨论之外。这种做法使团队找到了解决所有问题的办法。
—— Janet
每当讨论一项功能如何运转或者一个接口应该如何定义时，测试人员都可以与开发人员和业务专家讨论。测试人员绝不应该阻碍一切客户和开发人员之间的沟通，他们要确保沟通是有效的。
敏捷测试人员从客户的角度思考每一个故事，但是也理解实现功能相关的技术和局限性。他们可以帮助客户和开发人员达成共识。业务人员和软件人员经常使用不同的语言。他们不得不找到一些共同点来展开协作。测试人员可以帮助他们拥有一种共通语言。
Brian Marick（2004）提倡我们应该使用实例来定义这种语言。当Lisa的团队在sprint规划会议中偏离主题成为哲学讨论时，Lisa要求产品负责人提供一个示例或者使用场景。测试人员能够通过更多的示例活跃讨论。这有助于客户更清晰地设想他们的需求。测试人员也会帮助开发人员编写精心设计的代码以满足需求。？
面对面的沟通是不可替代的。敏捷开发依赖于持续的合作。就像其他敏捷团队成员一样，从事测试工作的人会不断寻找客户和技术团队成员来讨论和合作。当敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时，她会与客户和开发人员讨论。如果处于不同地点的人需要交谈，他们会试图寻找创造性的方式替代面对面、实时的交流。
（4）勇气
勇气是极限编程的核心价值，类似测试自动化和持续集成的方式允许团队实践这种价值。开发人员有勇气修改和重构代码，因为他们拥有自动化回归测试集的安全保护。在本节，我们将讨论敏捷团队转型中所需的勇气。
你是否曾经在这样的团队中工作：测试人员固守于自己的领域，不与其他业务相关者和技术团队进行任何讨论。虽然你找机会进入了协作的敏捷环境，可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。
当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时，通常你会产生恐惧感，并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成对每一个用户故事的测试任务？测试如何跟上开发的节奏？如何确定需要多少测试？又或者你是功能测试经理或者质量过程经理，但不清楚在敏捷团队中如何定位自己的角色，也没人知道答案。敏捷测试人员需要勇气找到这些问题的答案，但需要勇气的原因不仅限于此。
我们需要勇气允许自己失败，至少我们会有短暂性失败，我们要从失败中学习教训。在由于构建版本不稳定导致一次迭代失败之后，我们要开始寻找方法以确保这种事情不再发生。
我们需要勇气允许其他人犯错误，因为这是汲取教训的唯一途径。
Lisa的故事
我曾经参与过一个项目，当时的敏捷指导员坚持我应该呆在独立的测试团队里（通常只有一个人），其中的工作不包含在开发人员的跟踪和进度中。我不得不尝试一下。在项目由于测试没有完成遭遇麻烦之后，我询问敏捷指导员是否可以按照我希望的测试方式尝试一个或两个迭代。团队整体运作的方式是非常令人满意。在迭代结束之前每一个用户故事都被做了测试（并实现），客户对此结果更加满意。
—— Lisa
我们需要勇气寻求帮助，特别是当能够提供帮助的人看起来特别忙碌的时候。抛弃旧的制度，加入一个关乎项目成功与否的团队也需要勇气。提出问题或者指出你的想法存在缺陷需要勇气，即使是在遵循敏捷价值和原则的团队中。不要害怕，敏捷团队是开放的，通常都会接受新观念。
（5）简单化
Kent Beck的Extreme Programming Explained
（《极限编程解析》）建议我们尽可能做最简单的、有用的事情。这并不意味着你最先尝试的事情必须有用，但应该是最简单的。
敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。而是说，当业务部门的需求比较复杂的时候，团队可能需要将方案退回给他们，更简单的解决方案也会产生同样的价值。
我们中的某些人在软件公司以测试人员和质量保证人员的身份工作时，曾经被要求制定质量标准。我们认为这是一种倒退，因为应该由客户团队来决定他们想要的质量水平。测试人员和其他团队成员应该向客户提供信息并帮助他们全面考虑质量问题，包括非功能性需求，如性能和安全。最终决定由客户拍板。团队能够通过简单、逐步的方法帮助客户做出高质量的决定。敏捷测试意味着通过最简单的测试验证某项功能存在或者已经达到客户的质量标准（如性能）。
简单并不意味着容易。对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。
探索性测试能够用来了解应用程序和发现深藏的缺陷，但是应该从基本的、时间可控的测试开始，然后根据边界测试评估进展。简单性帮助我们关注风险、投资回报和改善最痛苦的问题。
（6）持续改进
想办法把工作做得更出色是敏捷测试人员应牢记的。当然，整个团队都应该具有这样的想法，因为敏捷的核心价值就是团队总是尝试更出色地工作。测试人员应参加团队总结会，评估做得好的方面和需要加强和改变的方面。测试人员把测试问题摆到整个团队中解决。团队通过采取过程改进实践（如总结回顾和阻碍代办事项等）最大程度地改善测试和所有其他领域。对于更严重的问题，团队一次只关注一到两个问题，以确保彻底解决了实际问题，而不只是做做表面文章。
敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物，以验证是否值得长期采用。
学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能，如探索性测试。可参加各种会议，加入邮件列表，阅读文章、博客和书籍以获取新思想。还要想办法自动化（或者从其他同事中获得帮助）平淡的或者重复性的工作，以此获得更多时间投入到宝贵的专业技能提升中。
Weyerhaeuser公司iLevel部门的软件质量保证负责人Pierre
Veragren指出了敏捷团队中经常见到的一种特点：“AADD（Agile Attention Deficit
Disorder），即敏捷注意力缺乏症”。任何无法快速学习的事物都可能被视为无用的。敏捷团队成员讲究投资回报率，如果他们无法快速理解，他们就会转移目标。当你每两周或者更短时间就要发布一个产品级的软件时，这个特点并不是缺陷。
总结回顾是一种重要的敏捷实践，让团队利用过去的经验把未来的工作做得更好。敏捷测试人员利用这种机会提出与测试相关的问题并要求团队集思广益地去解决它。这种方式使团队通过自我反馈来得到持续改进。
Lisa的故事
我们的团队曾经利用总结回顾会议获得了巨大的好处，但是我们认为需要一些新事物来帮助我们把工作做得更好。我建议维护一份“阻碍待办事项”，记录下影响生产力的各种条目。我写的第一条就是测试环境的响应时间缓慢。系统管理员找来两台便宜的计算机，把它们变成快速的新服务器。数据库管理员分析了测试数据库性能，发现单硬盘系统是个障碍，经理开了绿灯，安装了一个RAID以获取更好的硬盘访问性能。很快，我们就能够快速地部署构建和进行探索性测试了。
—— Lisa
（7）响应变化
在瀑布开发模式中工作时，我们习惯说：“抱歉，我们现在不能更改。需求被冻结了。我们将在下一个补丁包里做更改”。客户对此非常失望，因为他们意识到无法实现当前所有的需求。
在为期两周的敏捷迭代中，我们可能会说：“好的，先在卡片上记录下来，我们将在下一个迭代或者版本中实现”，但是客户知道他们可以获得想要的变化，因为他们可以控制优先级。
响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定，所以他们会说：“我已经测试过了，任务完成了”。持续的需求变化是测试人员的噩梦。但是，作为一名敏捷测试人员，我们不得不拥抱变化。周三，我们可能期望启动故事A和B，下周五做故事C。但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。只要我们持续与客户交流，我们就能处理这些变化，因为我们与团队的其他成员保持同步。
有些敏捷团队尝试提前准备下一次迭代，比如编写高层次的测试用例、捕捉业务满足条件或者记录示例。如果故事的优先级发生变化则这种行为可能只是浪费时间。但是，分布式团队非常需要额外的反馈周期为迭代做准备。
Lisa的故事
一个远程团队成员曾经是我们的现场经理。他在帮助企业客户编写和设定故事优先级方面起到了关键作用。他对编程和业务都有深刻理解，这有助于他提出创造性的解决方案以满足业务需求。当他搬到印度时，我们设法留住他以发挥他的专长作用。我们会定期安排与他开会，与产品负责人通过电话会议讨论未来的故事。我们不得不在能使用的各种工具中切换（从低技术含量的索引卡到在线工具）。
因为团队乐于通过有效的方式做出改变，寻找工具以确保跟得上变化，所以我们能够使他的专长继续发挥作用。
—— Lisa
某些团队的分析人员花费较多的时间与业务专家做提前规划。每一个团队不得不在头脑风暴式的预先解决方案和每一次迭代的第一天从头开始之间寻找平衡。敏捷测试人员与团队一起适应变化。
自动化测试是一个关键的解决方案。有一件事情我们可以肯定：如果只是手动测试，没有敏捷团队会获得成功。我们需要健壮的自动化方案以在有效的时间内发挥价值。
（8）自我组织
敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时，任何测试问题都会更容易解决。
Lisa的故事
我的团队是一个自我组织的好示例。当我们实施Scrum时，面对一个问题很多的遗留系统而且没有自动化测试。对代码的任何更改都存在风险。经理可能知道如何解决这个问题，但是他没有提出来。相反，我们研究了一下并拟定了一个计划。
开发人员开始在新的可测试的架构中实现新故事，采取测试驱动开发的模式。测试人员编写手动回归测试脚本，整个团队——
开发人员、测试人员、系统管理员、数据库管理员—— 在每个迭代的最后两天执行。与此同时，测试人员将执行用户界面的自动化冒烟回归测试。最终，新代码的架构让我们可以通过某些工具（如FitNesse）自动化功能测试。
我们在起步阶段实施了这项计划，并在每次迭代中改进方法。利用团队每一位成员的技能比我独断专行地决定自动化策略要好得多。
—— Lisa
当敏捷团队面对一个严重问题时，比如进度障碍或者构建失败，该问题将是所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定解决的办法和相关参与人员。
毫无疑问，Lisa的经理本来可以指定团队采用这个办法来解决自动化问题，但是团队自身能够提出一个有效的计划。当团队创建一个自己的方法并作出承诺，成员就会对测试采取新的态度。
（9）关注人
只有优秀的员工出色地工作，项目才会成功。敏捷价值和准则的宗旨是确保个人和团队成功。敏捷团队成员应该有安全感。不必担心因犯错受指责或者失去工作。敏捷团队成员互相尊重并认可个人成就。敏捷团队的所有人应该有机会提高和发展他们的技能。敏捷团队以可持续的步伐前进，使他们能够遵循严格的实践和保持崭新的视角。正如敏捷宣言所说，我们重视个人和合作超过过程和工具。
在软件开发的历史上，测试人员并不总是和开发团队的其他角色处于平等的地位。一些人认为测试人员在软件开发世界里是失败的程序员或者二等公民。那些懒于学习新技能和保持职业发展的测试人员加重了人们认为测试是低技能工作的看法。甚至连“测试人员”这个词都被敬而远之，代之以类似这样的头衔：“质量保证工程师”或者“质量分析师”，相关团队则更喜欢被称为“质量保证部”。
坚持敏捷理念的敏捷团队对所有团队成员会一视同仁。敏捷测试人员认为自己对团队做出了特有的贡献，开发团队认识到要想更加成功，团队需要拥有测试技能和测试背景的人。举例来说，一位熟练的探索性测试人员可能会发现自动化功能测试无法察觉的问题。一些测试经验丰富的工程师会提出其他人想不到的重要问题。测试知识是任何一个成功团队的组成部分。
（10）享受乐趣
在我们看来，测试人员的理想团队是：所有成员协作，从项目的开始一直到结束，利益相关者与开发团队共同工作，整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。
敏捷测试人员的工作特别令人满意，因为我们的角度和技能对团队产生了真正的价值。在下一节，我们将介绍如何实现那些价值。
4、创造价值
这些准则为团队带来了什么？总的来说，它们带来了业务价值。在敏捷开发中，整个团队负责研发高质量的软件使客户满意、企业盈利。这反过来为企业带来了新的优势。
团队成员承担了各种职责，敏捷开发模式往往避免划分成员角色。即使在短迭代和频繁发布过程中，客户团队的期望和开发团队的产品之间也很容易产生分歧。利用测试驱动开发有助于避免发生这个问题，但需要采取正确的测试。
敏捷测试人员不仅从利益相关者的角度考虑软件系统，也会了解开发团队面对的技术限制和实施细节。开发人员关注的是软件运行。如果他们满足了正确的需求，客户会很高兴。不幸的是，客户并不总是擅长表达自己的需求。使用错误的测试驱动开发不会产生期望的结果。敏捷测试人员会尽早并经常地向客户和开发人员提出问题，把他们的答案塑造成正确的测试。
敏捷测试人员采取更加综合的、面向团队的方法，有别于传统瀑布式项目中的测试人员。他们将自己的技能和经验贡献给团队和项目。有一种测试人员很迷恋在传统开发模式中学到的技能，他们是不会在敏捷团队中驻留太久的：他们把程序人员视为对手，或者坐等工作来主动找他们，或者希望花时间来规划而不是实践。
危险：你不是团队的“真正”一员
如果你是一名测试人员，但没有受邀参加规划会议、站立会议或者设计会议，你可能发现自己被视为开发团队的外人。如果受邀参加这些会议，但是没有发言，那么你给人的感觉是你不是团队的一员。如果业务专家完全依靠自己编写故事和定义需求，那么不像是敏捷团队中的测试人员。
如果处于这种状况，那么团队就危险了。隐含的假设直到开发后期才会被发现。当故事对系统其他部分的影响被发现时，则为时已晚。团队没有充分利用所有团队成员的技能，所以不会编写出最好的软件。沟通可能会中断，则难以跟踪开发人员和客户正在做什么。团队被分裂为开发人员和测试人员，这是一种不健康的状态，团队会脱离客户。
如何避免这种风险？看看你是否能安排自己坐在开发人员旁边。如果无法做到，至少走到他们的工作区域与之交谈并结对测试。让他们向你展示他们在做什么。让他们查看你写的测试用例。如果你没有被邀请参加相关会议，那就要不请自去。让自己通过测试和提供反馈变成有价值的人，成为团队必要的一分子。
帮助客户开发他们的故事和验收测试。敦促整个团队端正态度，解决测试问题。如果你的团队在实施敏捷开发时遇到了困难，建议在一两个迭代中实验新的办法。建议采取“三方协作”的规则促进良好的沟通。利用本书介绍的内容证明测试人员能够帮助敏捷团队实现超出想象的成功。
在故事估算和规划会议上，敏捷测试人员会从多个角度审视每一项数据：业务、最终用户、产品支持和开发人员。他们思考业务面临的问题和软件如何解决它们。他们提出问题，客户和开发团队澄清各种假设。在每次迭代的开始，他们帮助确认客户提供了清晰的需求和示例，帮助开发团队将其转换为测试。测试将驱动开发，测试结果将对团队的进展提供反馈。客户不会总是想到他们应该提出性能、稳定性需求或者安全考虑，但是测试人员应该询问这些问题。测试人员也会尽可能让测试方法和工具简单。在迭代的结尾，测试人员确认已经完成最低测试。
在敏捷团队里，角色之间的界线是很模糊的。其他团队成员可能也很擅长测试人员的工作。例如，分析人员和开发人员也会编写面向业务的测试。只要测试工作得到执行，敏捷团队不一定要指定某些成员为测试人员。但是，我们发现团队会从专业测试人员的技能中获益。我们谈到的敏捷原则和价值将帮助所有团队在测试和创造价值方面做得出色。
5、小结
在本章中，我们讨论了敏捷测试人员对敏捷团队有所贡献所应该具有的准则和价值观。
“敏捷测试思想”以客户为中心、注重结果、勤于耕作、协作、富有创造力、乐于学习和适时地创造业务价值。
态度很重要，它模糊了敏捷团队中测试人员、开发人员和其他角色之间的界线。
敏捷测试人员应用敏捷价值观和原则（如反馈、沟通、勇气、简单、享受和创造价值）以帮助团队识别和满足客户提出的每一个故事的需求。
敏捷测试人员通过自己独特的观点和面向客户的方法为团队和组织创造价值。 |
