敏捷測試 - 看板

可以使用看板概念有效管理敏捷測試活動。以下內容確保在迭代/衝刺中按時完成測試，從而專注於交付高質量產品。

• 可測試且大小合適的使用者故事能夠在指定的時間限制內完成開發和測試。

• WIP（在製品）限制允許一次專注於有限數量的使用者故事。

• 看板可以直觀地展現工作流程，有助於跟蹤測試活動和任何瓶頸。

• 看板團隊協作概念允許在發現瓶頸時立即解決，無需等待時間。

• 提前準備測試用例，在開發過程中維護測試套件並獲取客戶反饋，有助於在迭代/衝刺中消除缺陷。

• 完成定義 (DoD) 被認為是“真正完成”，這意味著只有在測試完成後，故事才算完成。

產品開發中的測試活動

在產品開發中，可以使用功能看板跟蹤版本。特定版本的特性分配給功能看板，該看板直觀地跟蹤特性的開發狀態。

版本中的特性被分解成故事，並使用敏捷方法在版本中開發。

以下敏捷測試活動確保每次釋出以及所有釋出結束時的質量交付：

• 測試人員參與使用者故事建立，從而確保：

  • 透過使用者故事和使用者故事中包含的非功能性需求來捕獲系統的所有可能行為。

  • 使用者故事是可測試的。

  • 使用者故事的大小允許在迭代內完成開發和測試（真正完成）。

• 視覺化任務看板：

  • 描述任務的狀態和進度

  • 立即識別出現的瓶頸

  • 便於測量迴圈時間，然後可以對其進行最佳化

• 團隊協作有助於：

  • 整個團隊對高質量產品的責任

  • 在出現瓶頸時立即解決，節省等待時間

  • 每個專業領域對所有活動的貢獻

• 持續整合，專注於持續整合測試

• 自動化測試以節省測試工作和時間

• 缺陷預防：提前編寫測試用例進行開發，並指導開發人員瞭解系統不同行為的預期：

  • WIP 限制，一次專注於有限數量的使用者故事

• 在開發過程中進行持續測試，以確保在迭代中修復缺陷：

  • 確保測試覆蓋率

  • 保持未解決缺陷數量較低

故事探索

故事探索是敏捷團隊內部的溝通，用於在產品負責人提交故事以供開發接受時探索對故事的理解。

產品負責人根據系統預期的功能提出故事。開發人員在標記故事準備接受之前會對每個故事進行更多探索。測試人員也會從測試的角度參與溝通，使其儘可能具有可測試性。

故事的最終確定是基於產品負責人、開發人員和測試人員之間持續不斷的溝通。

估算

估算發生在釋出計劃和每個迭代計劃中。

在釋出計劃中，測試人員提供：

• 所需測試活動的資訊
• 相應的努力估算

在迭代計劃中，測試人員有助於決定在一個迭代中可以包含哪些和多少個故事。該決定取決於測試工作量和測試進度估算。故事估算也反映了測試估算。

在看板中，只有當故事被開發和測試並標記為無缺陷完成時，才能實現“真正完成”。

因此，測試估算在故事估算中扮演著重要角色。

故事計劃

故事計劃在故事被估算並分配給當前迭代後開始。

故事計劃包括以下測試任務：

• 準備測試資料
• 擴充套件驗收測試
• 執行手動測試
• 進行探索性測試會話
• 自動化持續整合測試

除了這些測試任務外，可能還需要其他任務，例如：

• 效能測試
• 迴歸測試
• 相關持續整合測試的更新

故事進展

故事進展揭示了開發人員和測試人員之間持續溝通所導致的額外測試需求。在開發人員需要更多關於實現的清晰度的情況下，測試人員會進行探索性測試。

在故事進展期間進行持續測試，包括持續整合測試。整個團隊都參與測試活動。

故事驗收

當故事達到“真正完成”狀態時，故事驗收就完成了，即故事已開發和測試並標記為已完成。

當與故事相關的所有測試透過或達到測試自動化級別時，則認為故事測試已完成。