在中國的軟體行業，如果工作時間稍微長一點的話，應該都是從瀑布開發模式成長起來的，包括現在，很多公司其實還是採用瀑布開發的模式。當然，敏捷轉型也是軟體行業乙個很熱的topic。
作為乙個在傳統的軟體測試行業工作了8年多，在敏捷開發模式也工作了3年多的乙個測試行業的老兵，很想從測試自動化的角度看兩種開發模式的不同，以及測試自動化在其中的差異。
先從傳統模式說起吧，傳統模式下，軟體開發和測試人員分屬不同的team，之間其實是有很多隔閡的。特別當時我們和開發人員還屬於不同的site，溝通上面更加不是那們遍利。
記得那時公司要推測試自動化，我給其中的乙個基站測試部門介紹乙個我們新開發出來的工具，可以模擬手機打**，但當他們的測試經理聽到我說這個工具只能在協議層面來看通話是否暢通，不能真正判斷無線話路的暢通的時候，他馬上就打起了退堂鼓。
他的思路估計是這樣的，這個工具其實又沒辦法真正幫助我們取代人的勞動，還是需要人去做手工測試。那反正人會做的事情，為什麼要機器去做？他只對這個工具能夠提供的部分很難由測試人員手工執行的功能比較感興趣，比如做一些效能測試，做一些頻繁的切換測試等。
至於用它來做功能測試，雖然也能幫助他cover很多的功能，但是並不能引起他太大的興趣。特別是他有好幾個月的時間來執行乙個版本的測試，他手下又有這麼多的人，足夠來做測試，何必引入這麼個東西呢？
的確，對於乙個test manager而言，如果他的著眼點在於發現足夠數量的軟體bug的話，測試自動化的確不能幫助他太多。
有一種比較有意思的現象叫殺蟲劑效應，就是說如果同樣的case反覆執行，對於乙個特定軟體來說，發現問題的概率是越來越低的。
自動化case都是固定的測試過程，固定的檢查方式和期望結果，當然也不能期望他能夠持續不斷發現新的問題。
那到底我們為什麼要來做自動化測試呢？
在傳統的模式下，其實我也一直沒想清楚到底為什麼？特別是乙個自己也做過三年多手工測試，對自己發現問題的能力也頗有信心的人來說，我其實是挺能體會測試人員對推廣自動化測試的牴觸情緒的。
然後加入了現在的公司，我們公司在國內的敏捷開發陣營裡面，應該也算是比較前沿的。我的任務主要是在部門裡面推廣自動化測試，提高自動化測試的成熟度。
當時部門碰到的情況主要是已經有很多的自動化case了，但是這些case一直很難跑起來。具體來說就是乙個case失敗，往往後面很多case就會失敗。而且這個失敗，往往也不是真正的軟體bug導致的，很有可能還是乙個自動化case自身的問題引起的。
有的team呢，則是碰到這樣的問題，case執行得很順利，但突然某天就有幾個case失敗了，也不知道什麼原因。測試人員又無法通過手工測試復現，所以也是搞得莫名其妙的。
還有就是敏捷開發要求每天team需要把自己的case回歸測試一遍，但是隨著case的數量越來越多，team差不多要dedicate 0.5-1個人來跟蹤這些測試結果，而且往往也不能找到特別有價值的問題。而team日常又有新功能要開發，人力資源也比較緊張。所以漸漸地team也有疑問，這個事情每天做，到底有多大的意義？投入產出比合理嗎？
在上一家公司，我花了很多的時間來遊說測試部門多投入人力來搞自動化測試，但是收效始終不大，管理層的支援也不是很多。以致於到後來，我們team一致認為自動化測試搞不起來，技術問題不是主要的原因，公司的管理層理念能不能跟得上來，支援的方法是否正確，力度是否夠，才是最主要的。
現在公司的管理層態度很明確地支援這個事情了，不過碰到了一些困難，我是很有興趣進去看看，到底這些問題都是由於什麼原因引起的，能不能解決。
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 IV
後記 在做了一段時間的推廣自動化測試的工作，情不自禁地想把自己的眼光放得更遠一些，究其原因，我很清楚地認識到，測試的最終目的是還是為了提高軟體的質量，而無論是自動化測試，還是continous integration，都還是是軟體的外部看問題。但軟體為什麼一直有解決不完的bug，如果不對軟體的內部有...
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 II
我先是自己來除錯原來一直跑不起來的case，發現之所以前面的case失敗了，會影響後面的case，其實是由於case之間的獨立性不好引起的。為了能解決這個問題，我還和team一起設計了乙個複雜的環境恢復的keyword，裡面判斷了不同情況下，如果有板子沒有起來，應該怎麼恢復的問題。用了這個方法，ca...
瀑布模式開發與敏捷開發的比較
最近在學習一些敏捷開發相關的知識，覺得有必要和傳統的瀑布開發模式做個比較。因為瀑布模式仍然被很大程度在使用著，作為技術開發出身我有較深的體會，相信有針對行的對比分析會有更好的理解。關於瀑布模式和敏捷開發的基本特徵可以參照 個人理解對比如下 瀑布模型 敏捷開發 工作方式 1.以文件驅動,將軟體專案開發...