為什麼傳統的測試自動化工具無法滿足agile的團隊
Agile-Friendly Test Automation Tools/Frameworks
http://testobsessed.com/2008/04/29/agile-friendly-test-automation-toolsframeworks/
April 29th, 2008
Posted by Elisabeth Hendrickson
Hendrickson認為, 為什麼傳統 record-and-playback的商業自動化測試工具, 並不適用於agile的團隊, 理由有三
1. The test-last workflow encouraged by such tools is all wrong for Agile teams.
(1) Waste:
- 相同的資訊在manual and automated regression tests中重複出現, 或是大部分狀況下重複
(2) Feedback Latency:
- 通常傳統的自動化測試要執行很久, 可能要花數天或是一個禮拜, 因此導致feedback速度緩慢
(3) 無法支援 Acceptance Test Driven Development (ATDD)
- 因此無法在system level使用test -first approach
2. The unmaintainable scripts created with such tools become an impediment to change.
- 通常在record-and-playback的架構中, 會混合business-level的邏輯, 以及有關UI操控的一些的實作細節. 導致在維護上變成是一個噩夢
- Agile 團隊需要一種工具, 能把business level的邏輯, 和有關UI操控的細節分開, 這些才能使測試程式的設計穩固, 並且讓設計測試流程的人著重在使用者流程. 測試程式維護者能著重在UI操控的細節上
3. Such specialized tools create a need for Test Automation Specialists and thus foster silos.
- 通常這些tools都是用專門的script, 也就是只有這些公司專用的語言來開發, 因此你會需要找到一些專門懂這些工具的來做事.
- 因為這種人不好找, 所以一旦找到後, 所有自動化的事情都是他負責, 因為別人不懂, 無法分擔她的工作
Hendrickson 最後整理出agile team需要怎樣的測試自動化tools/frameworks:
- 能夠支援立即開始進行測試自動化, 也就是能配合測試先行的方式
- 能夠分離使用者流程和測試實作的細節
- 支持和鼓勵一些良好的programming practice, 讓這些practices也能套用在測試自動化的程式碼上
- 促進合作
- 能夠使用一般的程式語言或是IDE來開發測試程式
留言列表
