敏捷，开发&测试2

持续测试，提高交付速度和质量的敏捷和DevOps的团队
Waterfall的缺点：
1.1 测试人员和开发人员之间的接触点，当他们开始协作时，是在移交。开发人员会解释特性和需要测试的内容，但是没有上下文来允许测试人员集中精力。
1.2 对代码的更改只会在下一轮交付给QA，这可能是几周甚至几个月之后。如果变更引入了一个问题，那么它会在流程的很晚才被发现。如果大部分测试是手动执行的，那么这将花费更长的时间。
1.3 只有被认为是blocker的缺陷，阻止测试人员能够测试特性，才会被立即修复。其他缺陷必须等到开发人员进入错误修复阶段。当然，到那个时候，开发人员可能已经转移到其他事情上了，并且需要进行昂贵的上下文转换来记住特性以及需要做什么来修复它。
1.4 开发的时间通常比估计的要长，但是里程碑往往是固定的。剩下的唯一变量是质量，它总是会受到影响，因为为了减少发布的基本修复的数量，严重的缺陷会被重新考虑为中等优先级。
1.5 整合非常混乱。只有在项目的后期阶段，各个部分才会结合在一起，而且它们通常会根据不同的规格和理解进行开发。就像两个不太合在一起的拼图一样，这两个部分会被迫在一起，在这个过程中它们都会变形。
1.6 负载测试和安全性测试在开发周期的后期执行。在许多情况下，性能差的代码会被发布到生产环境中，因为没有时间重新架构设计糟糕的基础设施。
1.7 客户只有在产品发布后才能看到它。这已经超出了他们的反馈可以影响产品开发的范围。在某些情况下，当产品或特性发布时，客户不再需要它。
Agile
1.1 开发人员和测试人员从开发的一开始就在他们所做的工作上进行协作。在敏捷组织中，他们是同一个团队的一部分，与产品负责人一起理解和细化每个特性的外观，以及决定每个用户描述何时完成的标准。
1.2 团队的目标是交付最小可行产品(MVP)，这是为最终用户提供价值的最小功能。然后，团队定期发布额外的功能。目标是尽可能快地发布可工作的软件，保持一贯的高质量以快速获得用户反馈。
1.3 即使某个特性没有完全实现，开发人员也会定期检查主源代码存储库中的代码。只有已编译的代码(也传递特定的测试组)才允许进入源代码主干。如果发现错误，立即修复。
1.4 应用程序的不同组件定期集成。经常对集成进行测试。
1.5 比起手工测试，他们更喜欢自动化测试。尽管手工测试很重要，特别是对于新功能来说，团队的目标是编写能够作为与主源代码持续集成(CI)的一部分运行的自动化测试。
1.6 测试并不是唯一自动化的事情。许多组织正在自动化他们的基础设施，允许他们快速和重复地部署和配置测试和生产环境。
客户，或最终用户，从一开始就参与到产品的开发中。他们能够提供反馈，而开发团队能够根据反馈做出更改，从而产生满足最终用户需求的产品。
**ps:**风险往往在成本和用户体验之间。
Enabling Continuous Testing
持续的测试不会自发地发生，也不会没有持续的努力。相反，它需要计划、协作和正确的技术来启用和管理健壮的自动化测试。为了通过持续测试实现成功，过程和技术的结合是必不可少的。让我们来探究其中一些重要的促成因素：
Manual Testing (Exploratory Testing)
手工测试(探索性测试)当我们在增加自动化测试的覆盖率时，手工测试仍然是我们交付过程的一部分。当夜间构建完成并通过了所有自动化测试后，将手动测试构建的产品。我们对产品的特定领域，特别是新特性，执行端到端测试和探索性测试。发现频繁重复的缺陷的探索性测试被识别为自动化候选。
Testing Center of Excellence
测试中心 卓越测试中心(TCoE)仍然是我们持续测试的重要组成部分。几年前，TCoE是我们瀑布式开发方法的一部分，具有为TCoE构建的队列的每个产品都有一个窗口，可以在几个星期或几个月前定义，在那里他们可以测试我们的软件的性能或安全性。今天，虽然我们仍然有TCoE的概念，但我们以不同的方式使用它。在此之前，TCoE由专攻性能或安全等方面的工程师组成。但今天，这些工程师是管道的一部分，与产品团队的其他成员一起工作，测试每晚的构建版本。作为卓越中心(CoE)组的一部分，他们共享知识和经验，定义将使用的工具、如何使用它们，以及如何以标准的方式在整个组织内报告结果。
Automating the Infrastructure (Continuous Delivery)
自动化基础设施(持续交付) 配置基础设施(服务器、中间件、数据库和软件)可能是繁重且容易出错的，其中小错误可能导致重大的返工和交付团队的延迟。Jez Humble在他2010年出版的同名书中描述了持续交付的概念，详细描述了在所有环境(测试和生产)中配置和部署软件的广泛自动化的好处。通过配置和部署自动化，可以快速、准确地完成这些任务。驱动自动配置的指令(脚本)在源代码存储库中进行管理，就像任何其他代码片段一样，这就是为什么将基础架构称为代码的原因。通过自动化基础设施，我们可以快速而可靠地提供大量完整的测试环境。我们从不对配置进行手动更改。相反，我们对配置基础设施(服务器、中间件、数据库和软件)的更改可能是繁重且容易出错的，在这些地方，小错误可能导致重大的返工和交付团队的延迟。在Micro Focus 20脚本中进行持续的测试，并将它们检入到源代码控制中。然后，运行脚本以创建具有新配置的环境。在许多情况下，我们还可以自动化生产环境的供应。

----Container Technology
----Service Virtualization
----Test Automation Framework
----ChatOps and Bots