最近，關于下一代功能測試工具發展方向的討論熱鬧地開了鍋。不過，還是眾多組織仍然在努力讓傳統的“錄制-回放”測試工具跟上敏捷的腳步。被稱為“測試狂人”的Elisabeth Hendrickson告訴他們為什么不要再白費功夫了。
Hendrickson將她的看法出色地總結為下面這種索引卡片的形式：
為什么傳統的、“錄制-回放”式的、重量級的、商業化測試自動化解決方案做不到敏捷？
三個原因：
◆對于敏捷團隊來說，類似工具所鼓勵的“最后再測試”的工作流程是完全錯誤的。
◆類似工具創建的無法維護的腳本會成為敏捷所需的變更的障礙。
◆這樣的特定工具會需要專門的自動化測試專家，因此會形成單打獨斗的局面。
Hendrickson首先講述 “錄制-回放”式工具的“最后再測試”方式是如何難以取得成功的，而無關乎項目是否敏捷。她解釋了為什么這對敏捷項目來說尤其是個傷害。在敏捷項目中，“最后再測試”的工作流程至少有下列問題：
浪費：同樣的信息在手工和自動化回歸測試中會重復出現。實際上，它也在其他地方有所重復。不過我們可以先將注意力放在手工和自動化測試之上。
反饋延遲：這種工作流程中，大量的測試都是手工方式，這就是說要花費幾天甚至幾周的時間才能發現原先給出的變更所產生的效果。如果我們的Sprint是四周一次，那用三至四周的時間等待回歸測試結果就無法令人接受。進一步說，“最后再測試”工具無法支持“驗收測試驅動開發（Acceptance Test Driven Development）”。敏捷團隊需要的測試工具要支持“首先測試”的方式，并可以馬上開始進行自動化測試。
Hendrickson解釋了測試腳本如何成為這些“錄制-回放”測試工具的基礎，而且會無可避免地造成類似意大利面的混亂局面，將UI代碼中有關業務上的期待和具體實現細節混雜在一起，從而導致敏捷項目很容易變為一場維護的噩夢。她簡明地說：
敏捷團隊需要可以將要測試的業務實質內容與實現細節相分離的工具。這樣的分離是良好設計的標志，并可以增加可維護性。
接下來，在很大程度上出于考慮高昂成本和代碼所有權的需要，典型的“錄制回放”工具會將大多數組織引向創建專有的“自動化測試專家”小組之路，并且他們會被授權負責監控自動化測試。Hendrickson強調了這樣的方式是如何對有效敏捷所需的協作方式形成阻礙的。
敏捷團隊通過破除單干的局面來提升工作效率，這憑一些所謂的自動化測試“超級英雄”無法完成。也就是說自動化測試成為需要協作完成的工作。ac業務利益相關者、分析師和黑盒測試人員，他們都可以通過可自動化的形式（比如Fit表格）來做出對測試的貢獻；而程序員則負責編寫代碼將測試與實現相關聯。
最后，Hendrickson討論了敏捷團隊確實需要什么樣的自動化測試工具，并以此作為結束：
敏捷團隊需要的自動化測試工具或框架要像這樣：
◆要支持“首先測試”的方式，并可以馬上開始進行自動化測試。
◆將要測試的業務實質內容與實現細節相分離。
◆在自動化測試需要編碼的部分，支持并鼓勵好的編程實踐。
◆支持使用真正的開發語言、真正的IDE來編寫自動化測試代碼。
◆促進協作。
◆Fit、FitNesse以及相關工具可以達成上述要求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/