我们是极限编程(XP)的早期实践者，在完全不了解测试人员应该如何工作的XP团队中从事测试工作。那时候，敏捷(当时还没有这个称谓)资料中对验收测试和专业测试人员的工作方式介绍得很少。我们通过自身的经验和小规模敏捷社区这两方面来学习。在2002年，Lisa和Tip House合著了《测试极限编程》，该书的出版得到了Janet的大力帮助。从那时起，敏捷开发模式开始演变，敏捷测试社区不断繁荣。在众人的群策群力下，我们对敏捷测试的学习更加深入。 我们凭借个人和合作的力量帮助团队过渡到敏捷模式中，帮助测试人员了解如何在敏捷团队中贡献自己的力量，并与敏捷社区的其他成员紧密协作寻找让敏捷团队在测试方面更加成功的方法。我们两人的经历各异。Lisa作为一名敏捷测试人员在稳定的团队中工作了若干年，针对零售、电信和金融行业的Web应用。Janet则在软件公司中开发各个行业的企业系统。这些敏捷项目包括开发消息处理系统、环境跟踪系统、远程数据管理系统(包括嵌入式应用和交互网络)、石油天然气产品统计应用和飞机运输应用。她扮演过很多角色—— 有时是测试人员、有时是指导—— 但是她一直在努力使测试人员与团队的其他人更融洽。她参与团队的时间从六个月到一年半不等。 因为存在不同的视角，我们学会了合作和互补各自的知识库，并一起做了许多演讲和共同编写了许多教材。 本书的由来 目前，市面上已经出版了一些有关面向敏捷开发中的测试和测试模式的优秀书籍(见参考书目)。这些书一般关注于如何帮助开发人员。本书的目的是在帮助敏捷团队通过业务人员能够理解的测试来更加有效地创造业务价值。我们想帮助测试人员和质量保证(QA)人员从传统的开发模式过渡到敏捷开发。 在本书中，我们将讲述如何通过实用、逐步的方式应用我们在不同团队中的经验成果和来自其他敏捷先驱的思想，帮助测试人员、质量保证经理、开发人员、开发经理、产品负责人和其他任何致力于敏捷项目高效测试的人员，交付客户所需的软件。但是，我们更关注测试人员这个角色，因为很多专业人员都会担当此任。 敏捷测试实践不局限于敏捷团队成员。它们也可以用于传统开发模式项目的测试。我们希望能够帮助在任何开发模式下的测试人员。 敏捷开发不是成功交付软件的唯一方式。但是，我们参与过的所有成功团队，不论是敏捷模式还是瀑布模式，都存在一些共性。其中包括，程序员编写和自动化单元测试和集成测试(覆盖多数代码)，严格使用源代码控制和代码集成系统。测试人员从开发周期一开始就参与工作，并拥有足够的时间和资源来完成所有类型测试的任务。定期运行和检查自动化的回归测试集(在高层次覆盖系统功能)。开发团队理解客户的工作和需求，与业务专家紧密合作。 人是促使项目成功的关键，而不是开发模式或者工具。我们喜欢敏捷开发，因为它的价值、准则和核心实践能够让人出色地工作，测试和质量是敏捷开发的中心。本书将讲述如何将敏捷价值和准则应用到自己的具体测试工作中，并使团队取得成功。第1章和第2章将详细讨论这个问题。 编写本书的方式 因为体会到敏捷开发的益处，所以我们采用敏捷实践来编写本书。在开始动工的时候，我们与世界各地的敏捷测试人员和团队讨论了他们遇到的问题和解决办法。然后，我们计划如何在本书中包含这些内容。 我们制订了一个两周一迭代的发布计划。每两周在我们的图书网站上发布两章草稿。因为我俩身处异地，所以要使用工具交流，并对各章实施“源代码控制”，向读者发布书稿，并获得反馈。我们无法实时地“结对工作”，但是各章会经过反复的审阅和修订，并通过即时消息进行非正式的“站立会议”。 我们的“客户”就是敏捷社区中志愿审阅草稿的好心人。他们通过电子邮件或者亲自提供反馈。我们在随后的编写和修订中利用反馈作为指导。在所有草稿完成之后，我们针对修订做了新计划，其中包括了来自“客户”的所有积极的建议。 最重要的工具是思维导图。首先创建了一张思维导图描述全书的构思。然后对每一章创建思维导图。在编写各章之前，我们基于思维导图展开头脑风暴。在修订的时候，重新查看思维导图，帮助我们发现可能遗失的想法。 因为我们认为思维导图存在很大作用，所以在每章的开始部分包含了相应的思维导图。希望它们能够帮助你总览本章包含的所有信息，并鼓励你尝试使用思维导图。 读者对象 如果你曾经问过以下某个问题(我们已经听到过许多次)，那么本书将对你有所帮助： ● 如果开发人员编写测试，那么测试人员做什么？ ● 我是一名质量保证经理，公司正在实施敏捷开发(Scrum、XP、DSDM等)，我的职责是什么？ ● 我曾经在传统的瀑布式团队中做过测试人员，并且对敏捷非常感兴趣。我应该需要哪些知识来适应敏捷团队？ ● “敏捷测试人员”意味着什么？ ● 我是敏捷团队的开发人员，团队采用测试优先开发模式，但是客户仍然对我们交付的产品不满意。我们存在哪些缺陷？ ● 我在领导敏捷开发团队。质量保证团队无法跟上我们的速度，测试总是滞后。我们应该在开发的后一个迭代中测试吗？ ● 我是开发经理，最近转而采用敏捷开发，但是所有测试人员都离职了，为什么？ ● 我是测试人员，团队即将采用敏捷模式。我没有任何编程和自动化技能，在敏捷团队中还能立足吗？ ● 测试如何才能跟上两周一迭代的节奏？ ● 负载测试、性能测试、可用性测试等所有非功能性测试怎么办？如何在敏捷中实施？ ● 我们存在审计约束。敏捷开发和测试如何解决这些问题？ 如果你有类似的问题并且正在寻找切实可行的建议来指导测试人员如何帮助敏捷团队，以及敏捷团队如何有效地进行测试，那么这本书正适合你。 敏捷开发有许多“风格”，但是它们存在不少共性。正如在第1章所说的，我们支持敏捷宣言，不论你在实施Scrum、Extreme Programming、Crystal、DSDM，还是在实施自己的敏捷开发模式，都会在本书中找到有助于测试的信息。 敏捷测试书籍的用户故事 当Robin Dymond(一位帮助许多团队实施精益和敏捷模式的管理顾问和指导)得知我们正在编写本书时，给我们发来了他想要实现的用户故事，其中包含了许多我们计划满足的需求。 满足条件： ● 消除害怕失去对测试控制的担忧。 ● 消除必须编写代码(以前从未做过)的担忧。 ● 作为测试人员，要了解对团队的新价值。 ● 作为初次接触敏捷的测试人员，要能够容易地理解新角色中最重要的事情。 ● 作为初次接触敏捷的测试人员，要能够容易地忽略新角色中不重要的事情。 ● 作为初次接触敏捷的测试人员，要能够容易地获得对自身情况非常重要的敏捷测 试的更多细节。 当我考虑问题解决方案时，我想到了Scrum和XP。通过Scrum你能够简单地了解如何使大家快速实施敏捷。但是，Scrum只是成功敏捷团队的冰山一角。对于初次接触敏捷的测试人员来说，应该通过分层的方式向他们展示敏捷测试思想。今天应该了解什么？明天应该了解什么？应该为持续改进考虑与情境相关的什么具体事情？ 我们努力在本书中提供上述的细节，从全新的角度教授敏捷测试：过渡到敏捷开发、使用敏捷测试矩阵指导测试、解释在敏捷开发周期中发生的所有不同的测试活动。 如何阅读本书 如果不知道如何阅读本书或者想要快速浏览一下，我们建议阅读最后一章—— 第21章，然后随着它的引导来阅读。 第Ⅰ部分：简介 如果想快速得到如下问题的答案，如“敏捷测试和瀑布式项目测试有区别吗”、“传统测试人员和敏捷测试人员有何不同”，那么请阅读第Ⅰ部分，包含以下几章： ● 第1章：敏捷测试的定义 ● 第2章：敏捷测试人员的十条法则 这两章是Robin在其用户故事中提到的“冰山一角”，概述了敏捷和传统阶段式方法的区别，并引入了“整体团队”方式来进行质量保证和测试。 在本书的这部分中，我们讨论了“敏捷测试思想”和敏捷团队中测试人员成功的因素，解释了测试人员如何运用敏捷价值和准则来贡献他们的专业技能。 第Ⅱ部分：组织挑战 如果你是传统质量保证团队的测试人员或者经理，或者在指导一个团队转变到敏捷模式，那么第Ⅱ部分将帮助解决过渡期间遇到的组织挑战。“整体团队运作”代表了团队成员文化上的大部分变化，它有助于克服测试人员在害怕失去控制权或者被迫编写代码时的恐惧。 第Ⅱ部分回答了如下问题： ● 如何招聘质量保证团队？ ● 如何对待管理层的期望？ ● 如何组织敏捷团队，如何定位测试人员？ ● 聘用敏捷测试人员的标准是什么？ ● 如何应对分布在全球各地的团队？ 第Ⅱ部分也讨论了一些折磨人的主题，像如何过渡过程和模型，如审计或者符合萨班斯法案，这些要求在传统环境中很常见。 度量标准和如何利用它一直富有争议，但是存在一些有效的方式使团队受益。缺陷跟踪很容易成为团队的争论焦点，热点问题包括“我们使用缺陷跟踪系统吗？”或者“何时记录缺陷？” 来自传统测试团队的人员通常会询问两个常见问题：“如何制定测试计划？”和“测试项目中没有任何文档，是真的吗？”。第Ⅱ部分将解开这些谜团。 本部分包含以下各章： ● 第3章：文化挑战 ● 第4章：团队构成 ● 第5章：迁移传统过程 第Ⅲ部分：敏捷测试象限 你想知道敏捷团队中实施的测试类型吗？你想知道谁来做哪种测试吗？如何判断所需的全部测试都已完成？如何判断哪些实践、技术和工具最适合你的情况？如果有上述疑虑，请阅读第Ⅲ部分。 我们采用Brian Marick的敏捷测试象限来描述测试的目的。象限可帮助定义测试的不同领域，从单元测试到可靠性测试和其他非功能性测试，以及介于两者之间的一切测试。我们将讨论如何交付高质量的产品，介绍有助于沟通客户和理解其需求的工具。此部分展示了测试如何在各个层次上驱动开发，同时提供了工具帮助你有效地定义、设计和执行支持团队和评判团队的测试。本部分包含以下各章： ● 第6章：测试的目的 ● 第7章：支持团队的面向技术测试 ● 第8章：支持团队的面向业务测试 ● 第9章：面向业务测试工具包 ● 第10章：评价产品的面向业务测试 ● 第11章：利用面向技术的测试评价产品 ● 第12章：测试象限总结 第Ⅳ部分：自动化 测试自动化是敏捷测试团队成功的关键，而且对很多人来说是个可怕的话题(我们知道，因为之前我们对这些生活题材曾感到过恐惧)。如何把测试自动化塞进短迭代中，而且保证项目顺利完成？ 第Ⅳ部分详细讲述了自动化的时机和理由、克服自动化障碍的方法，以及如何确定和实施适合自身团队的测试自动化策略。因为测试自动化工具的发展非常迅速，所以我们的目的不是介绍如何使用某个具体的工具，而是帮助你选择和使用适合自己的工具。敏捷测试自动化经验将帮助你面对各种挑战，如测试遗留代码。 本部分包含以下两章： ● 第13章：自动化的原因和障碍 ● 第14章：敏捷测试自动化策略 第Ⅴ部分：测试人员的一个迭代 如果只是想知道在敏捷测试周期中测试人员是如何工作的，或者想把本书的内容综合在一起，那么请阅读第Ⅴ部分。我们以测试人员的身份讲述了一次迭代的经历。首先，我们参与计划发布和迭代使某次迭代有个良好的开端，然后进入迭代，与客户和开发团队协作，测试、编写代码。迭代的最后是发布新功能，并想办法改进过程。 本部分包含以下6章： ● 第15章：测试人员在发布或主题计划阶段的工作 ● 第16章：迭代前的准备 ● 第17章：迭代开始 ● 第18章：编码和测试 ● 第19章：迭代结束时的收尾工作 ● 第20章：成功的交付 第Ⅵ部分：总结 在第21章，我们列举了敏捷团队取得测试成功的7个关键要素。如果你不知道如何开始敏捷测试或者如何改进当前的工作，这些成功要素将对你有很重要的指导意义。 其他内容 本书还包含了词汇表和参考书目(书籍、文章、网站和博客)，希望对你有所帮助。 现在就开始实践—— 从今天开始！ 敏捷开发的目的其实就是出色地工作。每一个团队都面临自己的挑战。我们努力把自己想到的可能会帮助敏捷测试人员、团队、经理和客户的信息都分享出来。请根据自身情况选择合适的技术。不断地实验、评估结果，然后重新翻书看看哪些能助你进行改进。我们的目标是帮助测试人员和敏捷团队交付最优秀、最有价值的产品，并享受这个过程。 我们曾询问Canoo WebTest的创始人和项目经理Dierk König，敏捷测试的第一成功要素是什么？他说：“现在就开始实践—— 从今天开始！”。你可以现在就启程来改进团队的测试工作。现在就开始吧！