敏捷显然席卷了 IT 行业。几年前，在我试图将敏捷引入项目的早期，我什至不得不解释敏捷的含义。现在几乎所有我的客户都在他们组织的某个地方使用某种敏捷。现在我们看到了以敏捷方式支持交付的热点挑战，以及如何优化上市速度。一个常见的障碍是测试的持续时间和工作量。太多的组织仍然依赖大规模的手动检查，而不是采用优化的自动化测试方法。当然，在大多数情况下，并非所有事情都可以自动化，但自动化程度过低的情况比自动化程度高的情况要普遍得多。
“质量不是来自检验，而是来自生产过程的改进。” – W. Edward Deming 博士
上图说明了真正支持加快上市速度所需的转变。质量需要从一开始就融入到开发过程中，并且应该利用每个早期反馈的机会来避免人工检查的后期检测。有如此多的证据表明，发现缺陷的时间延迟代价非常高。人们不一定还记得几周前进行特定更改时他们到底在想什么。或者更糟的是，修复程序甚至可能交给完全不同的人，他首先必须了解他要修复的代码段的上下文。
对于许多组织来说，这是一个挑战，因为大多数测试都是由卓越测试中心集中组织的。这需要改变。
与其让这一大群集中组织的测试人员，不如让我们的敏捷团队中嵌入注重质量的人员。仅执行测试脚本的手动测试人员大多已成为过去。新角色需要了解业务环境并能够提出测试策略以最大限度地降低应用程序风险的人员。那些测试专家是那种在一条路上看两边的人，他们只是与其他人有不同的想法，因此具有我们需要的非常具体的心态。
“优秀的测试人员是那种在穿过单行道之前会向两边看的人”
除了创建测试策略外，他们还将负责探索性测试，以发现通常边界之外的事物。然后我们需要测试自动化开发人员，他们也应该嵌入到敏捷团队中。质量专家的分散并不意味着不需要中央职能。测试自动化需要一个应该由中心功能拥有的技术框架。此外，中心职能应确保分享经验教训和其他经验，并确保自动化开发人员、测试策略师和探索性测试人员的职业不断发展。提供交流机会、知识共享会议以及关于如何尽早将质量嵌入开发过程的更正式的指导应该成为新的重点。这也意味着与开发和工程团队就编码标准、静态代码分析的使用方式以及自动化单元测试可以涵盖的内容进行协作。在最基本的层面上，这是从测试到质量工程的转变。
中心职能的性质将从卓越测试中心转变为质量工程中心。这会很困难且具有变革性吗？是的，我会把这个想法留给你，所有 TCOE 从业者（以及与此相关的测试人员）都应该牢记在心：
“没有必要改变。生存不是强制性的。” – W. Edward Deming 博士