本文首先將討論sprint測試和開發(fā)中的一些長期障礙，然后尋找一個可行的辦法，以在短時間內交付經(jīng)過嚴格測試的系統(tǒng)。

這種方法的兩大因素是數(shù)據(jù)和自動化，它們協(xié)同工作，將有關需要測試的見解轉化為嚴格的自動化測試。但首先，讓我們來思考一下為什么在sprint中設計、開發(fā)和測試仍然如此具有挑戰(zhàn)性。

20 年后，獨立組織仍然是軟件交付方面的挑戰(zhàn)。

盡管敏捷宣言已發(fā)布20年，軟件交付生命周期仍然充滿了獨立組織。這些獨立組織不僅造成耗時的錯誤溝通，還擴大了人工的工作量。每次信息從一個移動組織轉移到另一個移動組織時，都需要將其從一種格式轉換為另一種格式：

這些"信息躍點"延遲發(fā)布并引入缺陷，因為誤解在每個階段都出現(xiàn)。現(xiàn)在，讓我們更詳細地查看每個獨立組織。

設計

從測試和開發(fā)的角度來看，在基于文本的文檔和不同的圖表中收集需求根本不適合使用。零碎的書面用戶情景和文檔與需要開發(fā)的確切邏輯很不一。同時，基于文本的格式和靜態(tài)關系圖之間通常很少或沒有正式的依賴關系映射。

發(fā)展

因此，軟件設計在轉換為源代碼時會引入錯誤，進而產(chǎn)生耗時的返工。事實上，多項研究估計，需求造成了一半以上的缺陷，而進一步的研究估計，開發(fā)人員花了一半的時間修復錯誤。因此，設計缺陷占用了開發(fā)新功能的大量時間。

測試

需求的靜態(tài)特性進一步增加了測試中的人工工作量。“平面”文檔和圖表還沒有為自動化做好準備，測試人員常常被迫手動將設計轉換為測試用例、數(shù)據(jù)和腳本。

除了浪費時間，這些手動流程還會降低質量。如今，一個簡單的系統(tǒng)可能需要數(shù)千次測試才能發(fā)布。面對非正式和不完整的要求，測試人員無法系統(tǒng)或自動識別和創(chuàng)建在發(fā)布前需要執(zhí)行的測試。

相反，手動測試設計幾乎完全側重于"快樂路徑"方案，過度測試這些方案，而犧牲了最有可能導致Bug 的方案。同時，過期和無效的測試堆積起來，導致測試失敗，使測試進一步落后于版本。

自動化可以提供幫助——但只有當它擴展到測試執(zhí)行之外時。

當然，自動化可以加速許多手動流程。然而，到目前為止，"測試自動化"幾乎完全集中在一個任務上，即執(zhí)行測試。在這樣做的過程中，它引入了大量手動流程，而忽略了關鍵的質量問題。

在許多情況下，測試自動化引入了一個新的獨立組織，以及與之相關的所有時間和精力。測試自動化引入的手動過程包括大量測試腳本以及大量腳本維護。同時，測試執(zhí)行的速度和數(shù)量會增加數(shù)據(jù)供應瓶頸，而過時或不一致的數(shù)據(jù)會導致耗時的測試失敗。

進一步自動化測試執(zhí)行對提高測試質量沒有任何幫助，也無助于識別要運行的測試。測試設計人員和自動化工程師仍然面臨著擁有比在sprint中執(zhí)行更多的系統(tǒng)邏輯的挑戰(zhàn)。

對錯誤測試進行優(yōu)先級排序不僅會浪費測試腳本中的額外時間，還會使關鍵系統(tǒng)面臨破壞性的生產(chǎn)缺陷。因此，測試執(zhí)行自動化是sprint測試的關鍵組件，但它本身并不是解決方案。

"數(shù)據(jù)驅動"測試，但不是你所知道的那樣。

幸運的是，一個解決方案正在出現(xiàn)。它在于數(shù)據(jù)，以及可以將自動化應用于當今廣泛可用的數(shù)據(jù)的方法。這為在sprint中準確自動地劃分測試優(yōu)先級打開了大門，在下一個版本之前生成所需的測試。

DevOps工具鏈中(自動)技術的激增導致了相關的數(shù)據(jù)激增。此外，這些數(shù)據(jù)現(xiàn)在以可捕獲和分析的格式輸出。

如果將這些數(shù)據(jù)與自動分析和測試生成相結合，就可以開始將最新的測試人工項目填充到收集數(shù)據(jù)的相同工具中。然后創(chuàng)建一個閉合反饋循環(huán)，收集和分析更多數(shù)據(jù)，以推動sprint中的嚴格測試。

現(xiàn)在來看看這個“數(shù)據(jù)驅動”的sprint測試方法的組件。

連接

此方法的第一個先決條件是跨應用程序交付生命周期的技術之間的連接。如果不同的工具不能在彼此之間傳遞信息，則獨立組織將持續(xù)存在。這將沒有足夠的數(shù)據(jù)進行分析，也不可能跨工具填充測試套件。

因此，技術之間的連通性至關重要，在sprint中，技術必須建立在開放技術之上。幸運的是，機器人流程自動化和DevOps編排工具可以幫助快速集成不同的技術。

基線數(shù)據(jù)

此外，還必須收集這些不同工具產(chǎn)生的數(shù)據(jù)，為收集數(shù)據(jù)提供基線。然后可以應用工具從這個單一的真相來源中獲取見解，告知測試人員sprint中需要測試的內容。分析工具包括但不限于基于AI和ML的技術。

sprint測試和數(shù)據(jù)生成

此時，已經(jīng)收集和分析了數(shù)據(jù)，指出了sprint中需要測試的內容。但是，如何構建和執(zhí)行對這些信息進行操作所需的測試呢?

第一部分是自動化測試生成，將此生成與基線數(shù)據(jù)分析聯(lián)系起來。第二部分在于根據(jù)已生成的測試自動生成和分配數(shù)據(jù)。這可以通過在測試運行時查找和生成數(shù)據(jù)的工具實現(xiàn)，為每次測試提供豐富且兼容的數(shù)據(jù)。

開放測試平臺

如果你擁有所有這些組件，那么就有了所謂的開放測試平臺。一個開放的測試平臺可以管理整個應用程序開發(fā)生態(tài)系統(tǒng)的數(shù)據(jù)，準確地確定在sprint中需要測試的內容。它還構建了運行這些測試所需的測試和數(shù)據(jù)，使用數(shù)據(jù)驅動的洞察來實現(xiàn)sprint測試自動化。

開放式測試平臺不是從系統(tǒng)需求和一系列獨立組織出發(fā)，而是分析整個開發(fā)生態(tài)系統(tǒng)中的數(shù)據(jù)。因此，它會隨著需求或環(huán)境的變化來通知和更新測試，而不是玩一個不斷的追趕游戲。

簡而言之，開放測試平臺支持sprint測試自動化。