敏捷測試現實與幻想

　　敏捷測試現實與幻想   軟件測試

　　如果您的公司正在實踐敏捷開發，你可能已經遇到和George Wilson相同的挑戰。作為AIG Computer Services的Business Group Manager，他同時還在TickIT管理環境中管理IBM 中端和PC開發項目，這些都需要ISO9001的QA認證?，F在，作為測試自動化工具廠商Original Software的共同創始人和總經理，他開始布道敏捷實踐，作為達到質量的最佳方式。

　　“敏捷項目對于QA來說，是一個領導(測試)整個過程極好的機會，”Wilson說。不該是開發者掌舵整個過程，測試員只是次要的地位，他推薦測試員應該帶頭起領導作用?！斑€有其他更好的人能消除用戶和開發者之間的鴻溝嗎?理解什么是必需的，怎樣才能達到目標?在發布之前如何確保質量?”這就要求QA team自身在敏捷活動中非常靈活，所以Wilson 列舉了以下的事實來揭穿一些常見的敏捷測試的謊言。

　　謊言一：你需要做單元測試——TDD測試足夠

　　TDD(測試驅動的開發 Test Driven Development)是一個好的開始，但是對于那些認為TDD就是全部的人，“對于絕大多數的商業開發來說，這顯然是不對的。即便是敏捷開發的強烈支持者也認識到使用大量測試技術的必要性….包括白盒測試、黑盒測試、回歸測試、壓力測試和用戶驗收測試(UAT)，”Wilson說。

　　因此，最有效的敏捷項目將會包括探索性測試(黑盒測試)的技術補充(而不是競爭)白盒測試?！昂玫奶剿餍詼y試將會在陷入深淵之前，發現開發者遺漏掉的問題?！盬ilson說。

　　謊言二：你可以重用單元測試，構建回歸測試集

　　傳統的位于開發活動后期的測試不是必要的，因為應用程序的每一行代碼都有對應的測試用例，有人曾經告訴過你嗎?“一些TDD支持者…建議通過重新組織單元測試，從用戶驗收測試(UAT)到回歸測試的一切都可以執行。Wilson說。

　　聽起來好像很有道理，Wilson認為這實際上是不現實的，因為TDD開發的白盒單元測試的粒度和目標，和后期的黑盒測試，目的完全不一樣?！皢卧獪y試全部的目標是驗證代碼做預期的事，回歸測試的目標是保證修改后的應用代碼沒有意料之外的，或者是意外的結果?！边@兩個目標不完全相同。如，檢查一個屬性是有效的日期格式，和對于給定的輸入，檢查字段的值包含預期的日期，是不同的。

　　謊言三：我們不再需要測試員或者自動化工具

　　不對。測試員執行“和他們的開發組同事不同的、但同樣有效的任務，”Wilson說，測試員應該在項目表(project table)上有同樣的位置?！皞鹘y的測試自動化工具沒能做到工具廠商宣傳的廣告效果，這已經是被廣泛公認的事實。也許廠商們(沒有惡意，Original)應該降低宣傳的規格?！?/P>

　　謊言四：單元測試后不再需要手工測試

　　沒有人會不同意手工測試是重復的、昂貴的、令人厭煩并且容易出錯的。雖然TDD可以減少手工做功能測試的工作量，但它不能替代更多的手工或者自動化的黑盒測試?！巴ㄟ^自動化捕獲測試員的操作過程，記錄他們的鍵盤按鍵和鼠標移動，測試員將會有更多的時間來做‘有趣的’、更有價值的活動，例如測試那些很難或者不可能自動化的復雜的場景。雖然手工測試發現錯誤是耗時的(因此也是昂貴的)方法，但沒有發現他們的代價常常會更大?！盬ilson說。

　　謊言五：不再需要用戶驗收測試

　　在Wilson經歷的敏捷開發中，驗收測試常常定位是“和客戶一起工具，解決不正確的需求”，而不是“糾正不滿足用戶需要的功能”。也許實際上兩點都有?！爱斢脩糇畛醵x他們的需求時，他們是基于他們最初的期望。當他們看到剛‘新鮮出爐’的系統時，他們總是會提出不同的或者額外的需求，”他說。

　　雖然敏捷過程可能會減少以上這些發生的頻率，Wilson認為，但指望敏捷方法完全杜絕它是不切實際的，所以不要期望完全消除用戶驗收測試?！爱斕岬狡髽I用戶正式同意用戶界面時，這尤其是真理，因為他們設想的和開發者是不一樣的?！?/P>

原文轉自：http://www.anti-gravitydesign.com