敏捷推薦圍繞應用建立足夠的單元測試和驗收測試，以構建足夠強壯的測試套件。然而，實際情況是：不是所有的應用都有配套的測試套件。敏捷測試討論組 中有乙個有趣的討論，提到如何為沒有任何自動化測試的應用進行測試，成員們提出了多種方法。
asad safari發起了這個討論，他說他的一 個應用沒有任何測試 ，團隊中的開發人員不熟悉單元測試，距離截止日期也只有3個星期的時間供團隊測試。他希望得到一些建議，指導如何在這樣的約束 條件下測試。
phlip回應道：他 曾多次處於類似環境 ，並推薦以下建議：
phlip指明：在這個大測試保護傘之下，如果時間允許，團隊可以開始編寫小規模的、目的更明確的測試。他還指出：雖然團隊可以在接下來的三個星期 等待上面的做法產生效果，編 寫和執行更小的單元測試應該馬上開始 。
adam sroka同意phlip的建議，並補充道：
沒錯，很多團隊碰到質量低劣的**時，會放慢速度，產出的價值也會減少，而這對於質量沒有任何好處。我們需要更實用的解決方案……如果沒有從一開始就加入 測試，那麼就很難完全把測試做好，這是沒問題的。但是就此認為測試沒有價值，這是錯誤的看法。測試雖然不完美，但仍有其價值所在。brian spears卻沒有被他們說服，他認為敏 捷不是魔法 ，在三周時間內恐怕沒法產生什麼好解決方案。他說：
敏捷不是魔法，對這種緊急情況的解決方案，如果有的話，就是要投入很多很多時間，這明顯不是敏捷的做法。adam反對這個看法，指出有很多團隊如果進入類似境況，都採用了敏捷。這是團隊變得有實效的機會，也是讓軟體變得更好的啟動之旅。
annette認為：這種情況最 應該做的就是用很多很多時間做手工測試 ，因為到了這個階段，自動化測試就太費時間了。推薦從重要的和與收入相關的功能開始測試。annette也 推薦了lisa crispin和janet gregory合著的agile testing 一書。
charles bradley提出了類 似的建議，不過他指出還要獲得乙個有條件的承諾 。他說：
你的時間很有限，所以從業務角度來看，將roi最大化是最佳選擇。就使出吃奶的勁頭做手工測試吧！但是要從你的老闆那裡得到承諾：他們無論如何也不 會再讓你的團隊這麼做了……他們應該先規劃好時間和金錢完成自動化測試……著手下乙個發布工作時就應該馬上開始，甚至更早，比如開 始修復當前版本的bug時。因此，編寫完整的測試套件，也許不是最適合當前情形的做法，團隊最好開始手工測試。而這並不能削弱在一有機會時就編寫適當的測試套件的做法。正如jonathan rasmusson 指出的：
你所能做的就是修復bug，然後在上線之前盡一切可能完成手工測試。這就是你到這個時候還能做的事情。更大、更重要的問題，是你在三周截止日期到達之後要 做什麼。
從桌面應用自動化測試看移動應用自動化測試
自從圖形化介面成為個人桌面電腦的主流，應用程式複雜程度與日俱增，針對人機互動的自動化測試迫在眉睫，從而在市場上湧現了一大批針對圖形介面應用程式功能測試的自動化測試工具 參考鏈結1 2001年qtp第乙個版本發布 2002年robot初始版發布。自此，自動化工具已經經歷了十年的發展。隨著近兩年移動應用...
手工 自動化 雲測，一窺應用測試簡史
1822年，英國科學家charles babbage開始製造他的第乙個差分機原型，用於計算多項式函式值，而巴貝奇差分機是人類歷史上第一台可程式設計的計算機，由此，應用測試時代拉開序幕 1843年，美國發明家愛迪生 thomas alva edison 在給西奧多 普斯卡什的信中用術語 缺陷 bug ...
web自動化測試 測環境搭建
1.使用說明 2.環境安裝方法 需要聯網哦！1 檢查是否已經安裝了python的直譯器 win r 輸入 cmd 回車 輸入 python回車 出現python的版本資訊，表示python直譯器是正常安裝的 輸入exit 退出python的直譯器的環境 2 win r 輸入 cmd 回車 輸入 pi...