敏捷測試之敏捷的軟件測試 必須糾正十大誤解

敏捷測試之敏捷的軟件測試 必須糾正十大誤解

敏捷方法已經獲得了越來越廣泛的應用。這是很容易理解的，特別是從開發人員與用戶的角度來看。

    1. 用戶——系統的需求與過程上的細節問題似乎永遠也問不完，然后還要仔細閱讀大量的說明文檔，而他們明白這些文檔會成為將來法庭上的證據。

    2. 開發人員——需要嚴格地遵循說明文檔而無法表達自己的想法或發揮創造性天賦。他們知道即使有更好的辦法，他們也不能更改說明文檔，否則這就會成為將來法庭上的證據。

    但是對于質量保證人員來說，敏捷方法卻會帶來麻煩——在原來的理想情況下，他們只需要用既有的說明文檔來驗證"完成"的產品。要根據一個變化的背景驗證一個活動的目標是很不直觀的。這表示所使用的技術與自動化也更復雜，并且需要一個新的測試方式，一種類似于用戶和開發人員之間的關系的方式。

    所有的敏捷方法都有（至少）一個共同的特征，那就是對QA職業的影響。如果所謂的影響是質量上的一次大飛躍，那倒也不是什么壞事。但是，如果決策是根據無效的范例做出的，改變就不一定能與過程同步了。對于開發人員來說，新提出的軟件開發范例以開發人員為中心可能是很平常的事。Abraham Maslow曾經說過："擅長用錘子的人喜歡從釘子的角度考慮問題。"但是作為質量保證人員，我們不能裝作敏捷開發不存在的樣子，我們必須保證那些拿著錘子的人不會去硬敲一顆螺絲。

    某些人可能會對QA提出懷疑，認為測試驅動開發（TDD）才是測試的關鍵。但是，伴隨著需求和方案的發展，QA在整個過程中都是與敏捷小組直接發生聯系的，是整個測試設計團隊不可或缺的一部分。但這只是QA團隊所面臨所必須解決的眾多誤會中比較表面的一個。

    對測試的誤解

    最近看了網絡上所謂專家寫的文章，發現了一些對TDD與QA部門的誤解。本文將解釋部分誤區，并集中討論QA團隊要在敏捷的世界里獲得成功所必須解決的一些問題。

    1． "你只需要做單元測試——TDD測試已經足夠"

    對于大部分商業開發來說，根本就沒有這回事。即使是敏捷開發的強力擁護者也承認他們需要一系列的測試技術。

    TDD程序設計人員需要這些測試來驗證代碼的正確性。如果需求（測試用例）解釋錯誤，那么你構建的代碼也將無法達到目標要求。

    大多敏捷項目都會使用探索性測試方法（黑盒）來支持白盒測試，而不會認為這兩種技術只能選一。優秀的探索性測試可以在開發地過于深入之前發現開發人員所忽略的問題。

    2． "你可以重用單元測試來創建回歸測試集"

    有些TDD擁護者認為常規的下游測試（downstream testing）是多余的，因為每一行應用代碼都有對應的測試用例；他們認為重用單元測試就可以做到用戶驗收測試和回歸測試所能做到的一切。

    這聽起來挺有道理，但由于某些原因，這是不現實的：TDD中的白盒單元測試的粒度與目標與下游黑盒測試的目的是不同的。

    雖然單元測試的整體目標是保證代碼能夠實現所需的功能，但是回歸測試的目標是保證被改動的應用代碼不會產生意料外的效果。這兩個目標是不同的--比如，檢查一項屬性是否具有合法的日期格式，與檢查輸入域中是否存在所需的日期是不同的。

    3． "開發人員可以用開源工具寫測試，因此我們不需要測試人員或者自動測試工具了"

    職業測試人員實現的是與其開發同僚不同但同樣有效的作用。

    人們普遍認識到傳統的自動測試工具并不像供應商們炒作的那么有效。原始軟件的源碼和供應商的產品一樣可以改善數據庫測試環境下的效率。這是因為沒有合適的工具可以提供用戶界面測試，所以我們才把方案擴展到了這一領域；我們的傳統是有效地實施測試而不是屏幕抓取自動測試。我們開發了測試驅動，是因為在過去的二十年里傳統的供應商錯過了這個機會。

    通常，TDD項目的測試代碼至少與應用代碼一樣多，因此其本身就是應用軟件。這種測試代碼是需要在目標應用的生命周期中進行維護的。

    4． "有了單元測試就不需要手動測試了"

    手動測試是一項重復性很強的工作；成本昂貴、枯燥并且容易出錯。雖然TDD可以減少功能測試所需的手動勞動，但是它不能消除對黑盒測試（手動和自動）的需求。

    通過自動抓取測試人員的過程并記錄其鍵盤和鼠標動作，測試人員能夠騰出更多的時間來進行更有意義、更有價值的活動，比如測試難以（甚至無法）自動化的復雜場景。雖然手動測試很費時間（因此也很昂貴），但是如果因為不進行手動測試而漏掉一些錯誤，則通常意味著將來可能要付出更大的代價。

    5． "我們不再需要用戶驗收測試"

    在敏捷開發中，用戶驗收測試的定位通常是和用戶協作確定"錯誤的需求"，而不是檢查功能是否與需求匹配。用戶在最開始定義需求的時候，他們是根據自己的期望值來描述的。當他們看到"活生生"的系統的時候，他們必然還會產生一些不同的、或者額外的需求。雖然敏捷方法可以減少這種事情的發生概率，但是要完全解決這種問題還是不可能的，因此我們無法回避用戶驗收測試。商業用戶的用戶界面驗證就更無法回避了，因為他們想象的可能與開發人員稍有不同。而這就得由我們來……

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