本文首先将讨论sprint测试和开发中的一些长期障碍，然后寻找一个可行的办法，以在短时间内交付经过严格测试的系统。
这种方法的两大因素是数据和自动化，它们协同工作，将有关需要测试的见解转化为严格的自动化测试。但首先，让我们来思考一下为什么在sprint中设计、开发和测试仍然如此具有挑战性。
20 年后，独立组织仍然是软件交付方面的挑战。
尽管敏捷宣言已发布20年，软件交付生命周期仍然充满了独立组织。这些独立组织不仅造成耗时的错误沟通，还扩大了人工的工作量。每次信息从一个移动组织转移到另一个移动组织时，都需要将其从一种格式转换为另一种格式：
这些"信息跃点"延迟发布并引入缺陷，因为误解在每个阶段都出现。现在，让我们更详细地查看每个独立组织。
设计
从测试和开发的角度来看，在基于文本的文档和不同的图表中收集需求根本不适合使用。零碎的书面用户情景和文档与需要开发的确切逻辑很不一。同时，基于文本的格式和静态关系图之间通常很少或没有正式的依赖关系映射。
发展
因此，软件设计在转换为源代码时会引入错误，进而产生耗时的返工。事实上，多项研究估计，需求造成了一半以上的缺陷，而进一步的研究估计，开发人员花了一半的时间修复错误。因此，设计缺陷占用了开发新功能的大量时间。
测试
需求的静态特性进一步增加了测试中的人工工作量。“平面”文档和图表还没有为自动化做好准备，测试人员常常被迫手动将设计转换为测试用例、数据和脚本。
除了浪费时间，这些手动流程还会降低质量。如今，一个简单的系统可能需要数千次测试才能发布。面对非正式和不完整的要求，测试人员无法系统或自动识别和创建在发布前需要执行的测试。
相反，手动测试设计几乎完全侧重于"快乐路径"方案，过度测试这些方案，而牺牲了最有可能导致Bug 的方案。同时，过期和无效的测试堆积起来，导致测试失败，使测试进一步落后于版本。
自动化可以提供帮助——但只有当它扩展到测试执行之外时。
当然，自动化可以加速许多手动流程。然而，到目前为止，"测试自动化"几乎完全集中在一个任务上，即执行测试。在这样做的过程中，它引入了大量手动流程，而忽略了关键的质量问题。
在许多情况下，测试自动化引入了一个新的独立组织，以及与之相关的所有时间和精力。测试自动化引入的手动过程包括大量测试脚本以及大量脚本维护。同时，测试执行的速度和数量会增加数据供应瓶颈，而过时或不一致的数据会导致耗时的测试失败。
进一步自动化测试执行对提高测试质量没有任何帮助，也无助于识别要运行的测试。测试设计人员和自动化工程师仍然面临着拥有比在sprint中执行更多的系统逻辑的挑战。
对错误测试进行优先级排序不仅会浪费测试脚本中的额外时间，还会使关键系统面临破坏性的生产缺陷。因此，测试执行自动化是sprint测试的关键组件，但它本身并不是解决方案。
"数据驱动"测试，但不是你所知道的那样。
幸运的是，一个解决方案正在出现。它在于数据，以及可以将自动化应用于当今广泛可用的数据的方法。这为在sprint中准确自动地划分测试优先级打开了大门，在下一个版本之前生成所需的测试。
DevOps工具链中(自动)技术的激增导致了相关的数据激增。此外，这些数据现在以可捕获和分析的格式输出。
如果将这些数据与自动分析和测试生成相结合，就可以开始将最新的测试人工项目填充到收集数据的相同工具中。然后创建一个闭合反馈循环，收集和分析更多数据，以推动sprint中的严格测试。
现在来看看这个“数据驱动”的sprint测试方法的组件。
连接
此方法的第一个先决条件是跨应用程序交付生命周期的技术之间的连接。如果不同的工具不能在彼此之间传递信息，则独立组织将持续存在。这将没有足够的数据进行分析，也不可能跨工具填充测试套件。
因此，技术之间的连通性至关重要，在sprint中，技术必须建立在开放技术之上。幸运的是，机器人流程自动化和DevOps编排工具可以帮助快速集成不同的技术。
基线数据
此外，还必须收集这些不同工具产生的数据，为收集数据提供基线。然后可以应用工具从这个单一的真相来源中获取见解，告知测试人员sprint中需要测试的内容。分析工具包括但不限于基于AI和ML的技术。
sprint测试和数据生成
此时，已经收集和分析了数据，指出了sprint中需要测试的内容。但是，如何构建和执行对这些信息进行操作所需的测试呢?
第一部分是自动化测试生成，将此生成与基线数据分析联系起来。第二部分在于根据已生成的测试自动生成和分配数据。这可以通过在测试运行时查找和生成数据的工具实现，为每次测试提供丰富且兼容的数据。
开放测试平台
如果你拥有所有这些组件，那么就有了所谓的开放测试平台。一个开放的测试平台可以管理整个应用程序开发生态系统的数据，准确地确定在sprint中需要测试的内容。它还构建了运行这些测试所需的测试和数据，使用数据驱动的洞察来实现sprint测试自动化。
开放式测试平台不是从系统需求和一系列独立组织出发，而是分析整个开发生态系统中的数据。因此，它会随着需求或环境的变化来通知和更新测试，而不是玩一个不断的追赶游戏。
简而言之，开放测试平台支持sprint测试自动化。
