最近一直在想
敏捷測試如何實施的事情，敏捷測試在敏捷開發中貫穿始末，涉及到了多種角色的參與：客戶、開發、設計、專職測試等等，每個角色承擔著不同的測試任務，客戶與設計可以進行驗證需求實現的測試，而開發進行
單元測試，專職測試人員進行詳細測試。
我們這里主要是來談談專職測試人員如何開展敏捷測試，其實這個問題也是很多軟件公司在研究的問題，我們公司也在摸索之中，今天就來介紹一下目前的一些情況。
首先介紹我們公司的情況，我們自己開發產品，大致主要有二條產品線，一條用敏捷方式，另外一條還是用傳統的瀑布方式，今天當然是介紹敏捷那條產品線。
在敏捷中，測試是從頭到尾一直參與的，而對于專職測試人員該從何時開始介入測試呢？各個公司都有自己的想法，對于我們公司而言，當一個功能已經設計好并且決定在這個迭代周期中開發時，測試人員就應該開始介入了。
怎么介入呢？
1、先從設計文檔著手，參考客戶需求看看設計文檔是否已經實現客戶的要求，對有疑問的地方與設計人員溝通清楚。當搞清楚整個設計思路以后，用腦中已經存在著的這個概念功能來寫測試用例。
這個測試用例需要共享給設計人員與開發，特別是給開發人員，因為他們開發的時候就能參照到這些測試點，避免出現未考慮到的地方。
2、當開發人員開發完成后，測試人員開始測試前或者測試中，需要進行討論會，討論什么呢，討論這個功能的測試覆蓋點。之前測試用例已經寫完了，但是這個 測試用例是基于一個想象中的功能的，實際的功能怎么樣子，誰都不知道。而現在實際功能做出來了，對于一個測試人員而言，就能得到基本的測試點了。而開討論 會的目的就是盡可能全的把測試點覆蓋，畢竟一個人的思維總是有局限性的，眾人拾柴火焰高。
不過，在敏捷中，功能是不定時做完的，可能今天做完2個，明天又做完3個，后天可能一個都沒有，所以這種討論會不是固定間隔的，一般情況下，累積幾個功能以后開一個討論會。
開討論會之前必須做好準備工作，也就是參與者需要提前看過這個會議中需要討論的功能，可以會前給大家一個小時或者半個小時研究一下。而在會議中，功能的實際測試者需要將大家對于這個功能的討論測試點記下來，之后更新之前寫好的測試用例。
通過這個討論會的方式，可以有效地提高測試覆蓋面，從而提高產品質量。
當一個功能開發完成以后，測試人員就可以開始按照設計完成的測試用例來進行測試了。在測試過程中，我們也需要注意很多地方：
1、首先，雖然測試可以根據測試用例來測，但是一個產品如果需要覆蓋很多環境，比如數據庫，瀏覽器，操作系統等， 你要全部覆蓋到，我相信幾個Sprint都沒法測完，所以怎么解決的呢？我們是按照迭代測試的方式來解決，簡單而言，就是把一個功能的測試分成幾輪，第一 輪可能在SQL+IE+Win7上測，第二輪呢，則在Oracle+Firefox+W2008上測，第三輪。。。。。。這個方法相對于我們現在的人力資 源來說比較合適，因為理論上你要測試全的話，測試的組合個數就是各個環境個數乘在一起，DB（SQL+Oracle+Access）×瀏覽器 （IE+Firefox+Chrome）×操作系統（Win7+W2008+W2003）=27，這個是窮盡測試，的確可以測得很全，但是耗費的資源太 多，一般都不太可能采用。我們實際測的時候，只需要考慮三個組合： SQL+IE+Win7，Oracle+Firefox+W2008， Access+Chrome+W2003，這種方式有個好處就是既覆蓋了所有測試點，又兼顧了時間與人力資源。
2、既然只有三個組合，那為什么還要分成不同的輪次測同一個功能呢？這個里是很有考慮的，首先，我們測試第一輪的時候，必然會發現Bug， 開發修Bug可能會導致其他Bug產生，這些需要我們再做回歸測試；第二，敏捷歡迎變更，功能的變更是家常便飯，所以一旦一個已經做完的功能發生變更，就 需要我們重新測試過；第三，對于一個功能的測試，我們知道每個人總是有思維定式，如果能有不同人來測試同一個功能，可能會發現很多不一樣的Bug。基于這 些方面的考慮，我們設計了一個功能需要經過起碼三輪的測試，第一輪是最主要的測試，測試完畢這個功能就應該是基本可用了，后面兩輪屬于回歸測試，確保修復 Bug和做過變更過的功能依然可靠，并且用不同人的角度來測試同一個功能。
3、分成三輪，其實還有另外一個也很重要的考慮，由于是敏捷 方式，所以對于時間的把握很重要，我們希望每個Sprint都能產生一個可用的產品，可以讓客戶來體驗新做的功能，而測試往往是個攔路虎，因為既然要測， 我們就像測得仔細，覆蓋很多地方，那這個就需要時間，時間是敏捷的敵人，所以我們就在想，既要能快速得到Build，讓客戶去看，又要保證質量，只能采用 分步的方式來做，先在最常用的環境里進行測試，保證基本功能正常，可以給客戶評估測試，然后接下來再通過幾輪測試保證這個功能的質量。
采用了這種方式來進行敏捷測試，其實給整個測試團隊帶來了很大的壓力，我們需要更快的反應速度，更高的責任感，更強的掌控能力，一旦某一環失控，之后都是 一個連環失控的局面，比如這個Sprint有功能來不及測完，下一個Sprint已經開始，新的功能又開始過來，你得先測完上個Sprint的，因為有客 戶等著看，但是這個Sprint又在大量累計功能，最后越堆越多，而且在測試理論上，Bug如果在早期發現，修復成本最低，一旦早期沒有發現，之后又在 Bug的基礎上做了其他功能，最后導致了連環Bug，修復成本會高得離譜。所以如果更高的要求能帶來產品更好的質量，當然是很值得的，而且對于員工個人能 力的提高也非常有幫助。
敏捷測試的實踐其實很多公司都在研究，但是真正能成功的可能還不多，其實我們已經試驗過很多方法，這次也是一個經驗總結后的繼續嘗試，相信很快能找到敏捷測試的真諦。