軟件敏捷測試是否寫測試用例(3)

　　appoint ： 測試肯定要用到測試用例。敏捷開發是靠測試來驅動開發，測試通過了開發就完成了。所以支持正方觀點

　　LoveTT ： 一看你就是科班出身，是做質量管理的吧!

　　什么事情都看得這個規矩，我覺得規矩沒有錯，但是規矩制約了發展就是錯誤了，你所謂的評審，審核，在一般的測試過程中是沒有問題的，而在敏捷測試過程中，他的測試團隊覆蓋面很廣，可以快速的識別問題并且修改問題，要是等待你的評審恐怕黃花菜都涼了!

　　魅力彩虹 ： 樓上LOVETT的觀點我不同意，你老說這個教條，那個是平時的工作，不是做敏捷測試。那請問一下你做過敏捷測試嗎?你的觀點依據又是什么呢?

　　LoveTT ： 根據我這個測試新手孜孜不倦的學習，倒是接觸過一些，記得前幾天IBM剛開了一個什么大會好像這個論壇中也有報道，我演戲了他的整個敏捷開發的過程，以及他的質量控制方法，所以我以此為依據說出上述論斷，大家要是有爭議，可以看IBM關于敏捷開發的文章

　　魅力彩虹 ： 評審用例不僅是規矩的問題，用例不去評審就盲目的執行，怎樣保證執行的正確性?發現了BUG怎樣反應給開發人員?有些用例你認為覆蓋了需求，你有怎樣知道自己執行的用例真正體現了需求的定義?如果根據個人臨時在大腦中想到的用例來測試系統，測試的有效性和以體現

　　LoveTT ： 《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

　　大家可以看一下這個兩本書!

　　所以我覺得敏捷測試有沒有設計測試用例，要不要評審，這個是兩個概念，樓上的跑題了

　　傲氣凌云 ： 但是在你工作中，你可以這么做嗎?即便是公司就你一個測試人員，也是需要編寫測試用例的。同樣，也就伴隨著評審等一系列活動。

　　shinnoshi ： 敏捷是少文檔，少流程，多溝通，使開發與測試更加緊密。不是不需要文檔，不需要流程，不需要測試用例。

　　請問你提及的測試通過，開發完畢是用什么來衡量的?

　　ash ： 敏捷的不是反文檔的。

　　測試用例最終生成也會以文檔數據方式存在，并且是顯性知識，是可以傳播、共享和繼承的。(不清楚看下面解釋)

　　我們應該清楚文檔的本質是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形態，顯性的和隱性的，傳統的觀念是盡量把隱性知識顯性化，即文檔化，而忽略了這其中的代價(特別是更新同步文檔的代價)。

　　因此，在實施敏捷的時候，需要在團隊內明確哪些知識是必須顯性的，這些知識可以通過文檔交流。哪些知識是可以隱性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。

　　new.bug ： 個人覺得，敏捷測試只是相對而言的，比如讓你測試一個比較復雜的系統，功能很多，那你說不用測試用例怎么比較有條理的進行測試?

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