TBOK的博客

敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程（Test-First Programming）。现在出现了（除了行为驱动开发以为，相关的还有像实例驱动开发（EDD-Example Driven Development），特性驱动开发（FDD-Feature Driven Development）等。各种驱动开发之间的关系众说纷纭这里我们来聊一聊测试驱...

版权说明本书为开源电子书，通过github维护。任何人都可以对该书进行投稿和修订。本参考书旨在帮助大家更好的学习敏捷测试，在尊重和注明来源的情况下，可以自由的使用和传播。 本参考书编写过程中，参考了大量的资料。文中尽可能的将所有参考的资料的来源做了标注。但是仍然可能存在一些遗漏的地方，如果对此有异议，可以及时联系我们进行更新。本文档处于持续更新中。为了便于维护和更新，最新的内容在Git...

敏捷中很多的实践都是来自于20世纪90年代，甚至更早。随着2001年敏捷宣言的提出，敏捷在IT领域的使用越来越广泛。这也说明了敏捷可以给大家带来很多非常好的帮助。这次要讲的内容并不是要来赞美敏捷的，而是希望从一些做的不好的方面来对敏捷在IT领域的应用做一些反思。希望能够触发大家对敏捷的一些思考。敏捷不仅是给原班人马换个称呼在团队刚开始准备向敏捷转型的时候，经常有人会问“原来的项目经理在...

你能想到的大多数测试类型都得益于自动化。手工的单元测试并不会阻止回归失败，因为每次在万事具备的情况下执行一套手工测试并不现实。你也无法通过手工的单元测试保证测试先行。一旦程序员不能通过单击按钮快速执行测试，他们就不想再执行测试了。我们可以通过手工的方式测试不同单元的代码以保证其正确运行，但自动化的组件测试是更有效的安全网。手工测试有助于发现功能上的缺陷，但如果没有足够多的自动化业务回归测试，我...

本节以不同的视角重新审视测试象限。先来仔细看看象限图，如下图所示：我们将支持团队的两个象限（象限一和象限二）标记为使用自动化。在象限四中，从技术视角来看，用于评价产品的工具通常也需要自动化。采用自动化业务测试工具来支持团队。只有象限三----评价产品的业务测试----没有标记为使用自动化。工具对于某些测试来说还是有用的，比如，自动化可以创建好测试数据和用户场景对日志进行分析。...

每个团队、每个项目以及每个企业都会遇到独有的自动化挑战。每个企业都有自己的文化、历史、资源、业务压力、产品和经验。无论你所在团队处于何种情况，你都可以使用敏捷法则和价值来寻找解决方案。勇气、反馈、简化、交流、持续开发和快速响应这些概念不仅仅属于敏捷，他们是所有成功团队所应具备的特质。1 保持简单保持测试设计简单、保持范围最小化，使用最简单的工具完成工作。简单是敏捷的核心价值。上手的最好...

探索式测试（Exploratory Testing）是 Cem Kaner 在 1983 年提出的。它是一种软件测试风格，强调测试人员的自由与责任的测试方法，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目过程中并行地执行。探索性测试在敏捷中广泛使用的原因大家可能注意到探索性测试的概念提出来的时间非常早，上个世纪80年代就出现了。但是...

当敏捷的春风吹在世界大地上的时候，最恐慌的是谁呢？不管传统项目中的其他角色的心情是如何的，大部分测试人员肯定是惴惴不安的。为什么？大家学习了敏捷后，发现其实没有测试人员什么事啊！在敏捷中，测试这个活本身还是在的，但是执行的主体发生了重大变化，那就是很多测试的职责从原来的独立的测试人员身上转移到了开发人员身上了。就像什么测试驱动开发、验收测试驱动开发、持续构建、持续集成、持续交付等，这些活动中都需要...

敏捷测试的本质测试遵循敏捷宣言进行，把开发作为顾客看待。项目的测试采用敏捷方法论。 敏捷测试的原则与上下文驱动测试的原则有交集，例如，上下文驱动测试的七大原则中的第三条：工作在一起的项目组成员是项目的上下文的最重要的组成部分。与敏捷宣言中的“个体和交互比过程和工具更有价值”一样强调人的作用。持续地对软件质量问题进行及时地反馈 。敏捷测试也意味着测试遵循敏捷的基本原则，接纳敏捷的核心价值...

看板看板方法，一般认为是由大卫安德森（David J. Anderson)发明创造的，于2004年诞生在微软的XIT项目，并于06年至07年之间在Corbis公司得到大规模运用，紧接着在全球迅速推广。大卫在发明看板方法之初，便深受了大野耐一的丰田生产方法（TPS），高德拉特的约束理论（TOC），戴明的质量管理，以及敏捷开发的影响。因此，看板方法中的很多概念，都可以从上述理论中找到影子。看板...

XP（Extreme Programming）的由来本部分关于XP的主要的内容参考的是Kent在2004年写的《解析极限编程-拥抱变化》，如果对比他在1999年出版的第一个 版本的话，你会发现其中无论是价值观、原则和实践都发生了一些变化，当然这个恰恰体现了敏捷的拥抱变化。XP中提到的价值观和各种原则很多都是思想层面和面对事物我们应该如何思考，他们不仅仅可以用在软件开发中，也可以用在我们生活...

敏捷宣言和原则2001 年，一批专家在对一系列轻量级软件开发中广泛使用的方法进行讨论后，同意将一些具有共性的价值观和原则汇集成敏捷软件开发宣言，或称为敏捷宣言[Agilemanifesto]。敏捷宣言包含以下四条价值观：个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划敏捷宣言认为，尽管右项是有价值的，但是更重视左项的价值。个体和互动...