軟件測試能夠以敏捷的方法進行嗎？

　　我一直認為敏捷是以開發為中心的，如果敏捷宣言尚且是對傳統軟件開發模式原則上顛覆的話，那么敏捷所帶來的N多最佳實踐更是以開發過程改進為目標的，信手拈來的就是TDD、CI、XP、PP等諸多實踐方式，就是跟測試拉上一點關系的UT和Aclearcase/" target="_blank" >cceptance Testing也是多由開發者自己來完成，那對專業測試工程師來說，當團隊進入到Agile的環境后，會有怎樣的不同遭遇呢?在Agile中如何到測試更有效呢?

　　測試在敏捷前后的不同

　　在敏捷環境中，測試可以早介入，從確認客戶需求開始，到測試計劃、測試案例、測試執行、缺陷跟蹤、回歸測試，一直到最后軟件系統發布，測試會貫穿在整個流程中，這是明顯區別于傳統的瀑布型模式的。這樣的優點毋庸置疑，讓測試專家從客戶的角度盡早的使用軟件，及早發現與需求相悖的問題，盡量減小因設計實現所帶來的缺陷問道所招致的維護成本。

　　這樣的描述會在所有“敏捷測試”相關的國內外資料中都能看到的，也是為大家所承認的。但具體問題具體分析，在不同的團隊構成、不同的軟件系統等條件下，所謂“敏捷測試”總不得不去面對一些棘手的問題。

　　測試在敏捷中的困境及對策

　　雖然測試工作的內容無非包括計劃、執行、回饋等幾個環節，這在進入敏捷環境后也不會有怎樣的變化，但面對采用了諸多開發最佳實踐的開發者以及會產生快速迭代出新功能的軟件系統，測試人員如何保持快速的響應，并實時地調整測試過程，是每個測試團隊不得不面臨的問題。即使是“敏捷測試”的推廣者們，在宣揚了測試早介入之后，也鮮有值得推介的測試實踐拿出手來。這對各個測試團隊無疑是個考驗，即使是采用了相同敏捷實踐的開發者也不會表現出一樣的生產力，只有測試工程師根據整個團隊的特點，總結出一套最適合團隊的測試模式，才是最理想的。

　　系統測試

　　不得不說的是，就算是“敏捷測試 ”也沒有考慮到系統測試在敏捷環境中怎樣做。這對一般不會太看重軟件性能和集成性的系統來說不算個大問題，但對具有大大小小系統性能測試需求的測試團隊來說，是不可想象的。測試早介入，在系統測試團隊看來似乎是場噩夢，對尚未穩定的架構施加系統性能測試，多半會引起系統測試工程師們徒勞無功，因為開發人員這時不會太介意性能上的問題，他們有更重要的功能還沒實現，但schedule如此緊張。如果中途需求變化甚至架構變化，開發者幾乎可能把設計實現全部推到重來(這也是拜敏捷所賜了)。那之前系統測試工程師花費大量精力和時間，發現的問題很可能就此不可重現不再有效。相對白白付出的工作量，如果這段時間用來做技術調研準備和自動化測試開發，效益不可同日而語。這里需要開發團隊和系統測試工程師相互配合，開發為測試定義一些系統測試的進入點，并及時對系統測試的defect作出響應，才是理想的行為。

　　分布式團隊

　　敏捷專家推薦開發測試工程師們坐在一起工作，這樣交流更加方便直接，減少溝通成本，這在軟件快速迭代、快速響應需求變化的過程中是相當重要的。每天有scrum，有defect可以快速交互。但這在分布式團隊中很難實現，兩支不同時區的團隊沒有重合的工作時間，開會時間安排成了問題，如何把各自團隊自己的scrum結果讓另一方也知道呢?除了從分配story方面盡量減少兩支團隊的story依賴和耦合外，就是需要采用一些特定適合的方式來解決。如果能克服時差，一塊scrum是最好的。不行的話，可以通過 scrum mail每天互相交換更新的狀態。

　　迭代測試+自動化測試

　　每個迭代都會有一些新的功能被開發出來，如何制定計劃既保證這些新功能的測試，又保證新功能或者defect的修復不會導致已有功能遭到破壞呢，這里有一些策略。首先是功能開發的迭代計劃，項目經理需要仔細考量不同的story在各個迭代之間減少依賴和耦合，軟件架構設計者也需要有同樣的考慮，這里有軟件可測試性的問題。這樣在測試人員介入后，不會發生牽一發而動全身，顧此失彼的問題。

　　另外就是在軟件系統隨著迭代的不斷進行，累加的功能越來越多，測試資源有限，不可能一直全面地測試到軟件系統的所有方面。除了前面提到的不同迭代的軟件交互很少依賴和耦合外，自動化的測試是保證不斷迭代后繼續保證軟件質量的不可缺少的途徑。自動化測試開發，這是另外一個話題，如果認為這全部只是測試工程師的責任，那就是短見和無知了。自動化測試要求軟件系統開發者能夠在UI上預先提供一些鉤子，供自動化測試開發工具抓取UI對象進行識別并操縱，完成模擬用戶的實際操作。如果這方面的軟件可測性也無法保證的話，測試腳本維護成本居高不下，影響軟件質量，除了測試工程師叫苦不迭之外，最終仍然會形成很多defect送到開發者的面前。所以，這是整個團隊的責任。

　　缺陷管理

　　軟件開始正式的迭代開發后，由持續集成所產生的軟件交付成為測試工程師的工作目標，但如果一些功能還沒有完全實現就因此產生了defect，測試工程師把它們記錄在缺陷跟蹤系統里面，越積越多，測試工程師據此為自己的工作量體現，姑且不說這對軟件質量沒什么意義，在功能實現徹底完成之后，之前的這些 defect中的大多數就會自行解掉設置無效，那么測試人員所做的又是大量的無用功了。需要時刻牢記在心的是，最終目標是軟件質量的提升，而不是 defect的數量。測試和開發足量的溝通交流，足以消除掉大多數無謂的defect，只有那些已經完成的功能跟軟件需求還相悖的話，才是真實有價值的 defect，值得記錄值得跟蹤。

　　團隊觀念

　　說到底，“敏捷測試”需要的是一支緊密協作的團隊，開發和測試工程師互相配合，充分溝通交流，為提升軟件系統的質量致力工作，不在意無謂的defect數量，減少功能模塊間的耦合依賴，提高軟件可測試性，合作開發自動化測試腳本。其實根本無需太較真在“敏捷”這個字眼上，更重要的是改進出最適合自己團隊的軟件開發測試模式。

原文轉自：http://www.kjueaiud.com