在做轉變的實施前，我們需要有心里準備，任何從傳統開發到敏捷開發轉變不可能一蹴而就，自然也沒有人能夠將一個傳統開發模式下的測試團隊一夜之間變成徹底的敏捷。對這些還沒有敏捷起來，但仍然以此作為目標的項目團隊我們建議循序漸進，基于筆者的親身體驗，提供以下實施的方法請大家參考。
首先我們建議采用迭代的開發模式作為向敏捷的模式轉變的起點。很多傳統開發模式或者基本上還是瀑布式的開發，或者是周期性的瀑布式開發，這些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布開發的不斷累加。換句話說，傳統開發是傳遞性的工作，一方完成，另一方接手。而敏捷活動的迭代行為更強調盡早開展各項活動，從迭代的一開始就協同工作，共同實現團隊迭代的目標。而一旦抵達迭代的周期中最后一個工作日，此迭代宣布退出。
當完成了向迭代活動的轉變完成后，接著，我們開始尋找項目過程、管理、執行中最緊要的問題，并使用敏捷開發中的最佳實踐來一一解決這些實際問題。也許，一開始這個過程是很緩慢，而且很難做到一步成功，但是必須通過不屑的努力和足夠的耐心，慢慢轉變團隊的固有思維方式，并最終努力獲得團隊對改進后結果的統一認可。而一個問題被解決，或者不再是項目中最嚴峻的問題時，我們應該開始尋找下一個待解決的困難了。重復這個過程直至成功的將團隊中有悖于敏捷原則和實踐的過程和方法調整過來，同時將正確的思路和方法帶給團隊。
在最近的幾次與其他敏捷測試團隊的討論中，我們同時了解到許多軟件開發項目中的測試團隊遇到過類似的一些問題，如開發團隊沒有做單元測試或做得太少，繼而在開發過程中的遺留了大量質量缺陷和頻繁的回歸現象。這使得測試壓力急劇加大，測試過程嚴重受阻，甚至影響到整個迭代的退出和項目的輸出結果等等。又或者傳統的開發中的測試團隊因為很少有條件去認識客戶，了解和實際用戶相關業務需求。測試腳本和用例的設計只是基于開發人員撰寫的功能說明。因此，難以做到對需求變化做出快速反應。經過討論，我們推薦給對這樣的團隊如下參考方案。
首先開始采用測試驅動開發 (Test Driven)。
開發人員首先要善于使用測試驅動開發方法寫每一行代碼，先寫測試腳本后寫代碼，并反復使用單元測試腳本驗證所寫代碼的正確性。
列出需求
為需求撰寫一個單元測試腳本
執行測試確信測試結果是失敗的
然后，寫上僅僅足夠的代碼以使得先前的測試可以通過
當所有測試通過了，便可以開始寫下一個測試腳本
針對需求有效的實現所有測試腳本
另外，當需要代碼重構時候，也應該先重構單元測試腳本，在改動代買之前同樣先改寫測試腳本。
盡早的開始測試，開始系統測試，不要等待到功能完全做好才開始。
了解計劃中的待實現的功能，了解其權重分配，設計系統測試和功能測試用例。測試執行的一開始可以是針對部分功能的，之后可以逐步擴展。接著開始采用迭代的過程完成測試任務，即將測試任務劃分為多個周期，一開始可以做些關鍵的功能性測試，可以對代碼中的可復用部分（組件，構件）做完整的安全測試，性能測試，壓力測試，并發測試，全球化測試等。接著的迭代周期可以做邊緣化的功能測試和其他測試，最后的幾個迭代應該用于回歸測試，和關鍵的性能和穩定性測試。
然后策略性的進行自動化測試，設計并開發可以用于日后回歸測試（Regression）和用戶接收測試（Acceptance Test）的自動化腳本，持續維護與開發這些腳本。自動化測試為團隊帶來的是長期效益，自動化測試的開發也應該首先選擇部分測試對象，例如，API，框架等比較穩定和關鍵的功能做功能測試的自動化；對產品的性能指標，壓力測試也要較早的制定自動化測試的計劃。
最后，要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統的需求分析，設計和開發。積極地參與前期工作，并迅速反饋給設計和開發其靜態測試結果。
而且，要做好敏捷測試，我們需要轉變測試等待開發的思想，測試人員需要了解開發，需要讀懂代碼，才能夠更好的幫助開發人員分析和分離復雜問題。有甚者，測試人員可以成為開發人員的后備力量。當團隊中需要更多的人撰寫代碼時，測試人員應該勇當其職。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
