《敏捷软件测试：测试人员与敏捷团队的实践指南》要点回顾（一）

    在敏捷团队里，个个都是测试人员。测试和质量是整个团队的职责，但是测试人员拥有独特的视角和技能。作为一名测试人员，你对发布客户满意产品的追求会帮助你克服遇到的挫折。不要害怕成为持续改进的代理人。让敏捷准则和价值指引你与客户和开发团队一同工作，在每个迭代中生产价值。

    1.使用全队参与方法；

    2.利用敏捷测试思维；

    3.自动化回归测试；

    关于这一点真是有点坑爹，敏捷团队里，本来测试人员就少，而且版本迭代速度有很快，通常不是一周或两周一个迭代，而是三两天就是一个迭代，或许这是一个借口。这本书是鼓励大家去做自动化测试实践，鼓励大家踏出测试自动化，即便是很小的一部分，毕竟敏捷测试离不开自动化，敏捷提倡持续改进。

    4.提供和获得反馈；

    5.构建核心实践的基础；

    这里说的核心实践主要内容是持续集成、测试环境、技术债务、增量工作、实践之间的协作。

    6.与客户协作；

    7.保持大局观

   敏捷测试的定义：

    理解测试人员在敏捷团队中执行的活动可以帮助你向团队展现测试人员可以创造价值。学习敏捷测试的核心实践可以帮助团队交付客户满意的软件。

    测试人员、开发人员、客户可以使用相同语言。

    敏捷测试关注业务价值和交付满足客户需求的软件，敏捷测试与传统测试的区别主要是后者只专注于需求一致。

    敏捷测试的“整体团队运作”方式意味着参与教父软件的每一个人都有责任教父高质量的软件。

    通过应用敏捷价值和原则来克服出现在你的独特情形中的测试障碍。

   敏捷测试人员的十条法则：

    提供持续反馈；

    为客户创造价值；

    进行面对面的沟通

    勇气；

    简单化；

    持续改进；

    响应变化；

    自我组织；

    关注人；

    享受乐趣

    “敏捷测试思想”以客户为中心、注重结果、勤于耕作、协作、富有创造力、乐于学习和适时地创造业务价值。态度很重要，他模糊了敏捷团队中的测试人员、开发人员和其他角色之间的界线。敏捷测试人员应用敏捷价值观和原则（如反馈、沟通、勇气、简单、享受和创造价值）以帮助团队识别和满足客户提出的每一个故事的需求。敏捷测试人员通过自己独特的观点和米昂想客户的方法为团队和组织创造价值。

   挑战文化

    在做出任何变化之前都应考虑组织文化。

    当整个组织重视质量的时候，测试i人员可以容易地融入敏捷团队，但是具有“质量警察”思想的测试人员很难融入敏捷团队。

    有些测试人员可能会在适应“整体团队”对质量负责的时候有困难，但是团队方式可以帮助克服文化差异。

    客户团队和开发团队必须在一起工作，我们展示了测试人员如何在促成这种关系发生重要作用。

    大的组织容易有更多的独立的专门团队在类似于交流和协作等领域面临特殊的文化挑战。

    测试人员采用敏捷成功的障碍包括恐惧、丧失身份、缺乏培训、以前使用新的开发过程的失败经历和角色间的文化差异。

    为了帮助引入变化和存进交流，我们建议鼓励团队成员讨论恐惧、庆祝每次成功（不管是多小的成功）。

    类似于“测试人员权利法案”的方针可以给测试人员信心来提出问题和帮助他们安心地学习和尝试新的想法。

    经理也面临自己的文化挑战，他们需要向测试人员提供支持和培训来使他们在敏捷团队中获得成功。

    测试人员可以通过提供经理追踪进度和确定投资回报率需要的信息来帮助组团队达到经理的期望。

    改变并不容易，所以需要耐心，努力提升自己的技能可以帮助你的团队。

   团队构成：

    要考虑团队结构的重要性，肃然测试人员可能需要独立的心态，但是把他们放到单独的团队可能达不到预期的目标。

    测试人员需要接触更大的测试人员社区来学习和实验新的想法。质量保证团地可以再他们的组织内创建这样的社区。

    整个团队i在一个地点很重要，这样可以粗剪协作；如果团队是分散的，应通促进交流的工具。

    在招聘时关注态度。

    没有正确的测试人员-开发人员比例。正确的大啊是：“这依赖于你的情况”。

    团队需要资质，应确认并解决他们自己的问题，并寻找进步得方法。他们不能等待其他人告诉他们做什么。

    如果团队在努力，管理层应该奖励促进团队交付业务价值的业绩，但不要城府个人。

    测试人员可以使用敏捷原则来改进自己的技能并增加他们带给团队的价值。他们需要有前瞻性并应该可以发现他们做出贡献的方式。

   迁移传统过程

    如何将传统面向质量的过程应用到敏捷环境中？

    正确的度量标准能够帮助团队运转正常以实现特定目标，并提供良好的投资回报。

    度量标准时可见的，应提供必要的里程碑以供我么做出决定。

    使用缺陷跟踪系统的额原因包括边界、用作知识库、用于跟踪。

    缺陷跟踪系统被滥用作沟通呢工具，记录和跟踪不必要的缺陷是一种浪费。

    所有工具，包括缺陷跟踪工具，需要整个团队使用，所以在选择工具时应考虑所有人的看法。

    测试策略是长期的总体测试方法，可以记录在静态文档中，测试计划应该对每个项目是唯一的。

    在简单地接受文档之前应考虑替代方案，例如，敏捷方法提倡小的增量开发、紧密协作，可能不再需要正式的跟踪性文档。把源代码控制系统的注释与测试连接起来可能是另一个选择。

    传统的质量过程和过程改进模型，如sas 70 审计和CMMI标准，能够与敏捷开发和测试共存，团队需要创新思维，一起解决问题。

    对于敏捷测试是否需要缺陷跟踪工具这个问题是有争议的，我们团队经理的要求是在15分钟内能解决的问题，就不在缺陷跟踪工具提。我的看法是，但凡不能在半个小时内修复，并且可以发布出来验证的都需要提问题单，因为人的记忆是有限的，打个比方，比如上周五你发现了多个bug，开发人员跟你说半个小时内能修复，但是要到下周一才能发布出来再测试，经过了周末，下周一发布出来的版本，你可能忘记了这个问题的存在。

    同样，测试管理工具是非常有存在价值的，特别是对于那些没有开始自动化测试的团队。测试管理工具应该把用例管理好，方便以后回归测试能自动化。

    这本书分成三部分，我也是分成三篇文章，下面会做敏捷测试象限的要点回顾。