轉自：http://blog.csdn.net/softerwarer/article/details/6901872
【本篇是《敏捷測試理論以及實踐》第五篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】
以前在《結合工具來實現敏捷開發》這篇文章中，我已經談到了我們公司目前的開發情況，在這裏也不再重複介紹了，反正主要就是用 TechExcel的DevSuite 系統來進行管理整個流程。至於很多人可能會問，既然敏捷了爲啥還要用工具，其實我是這麼想的，敏捷開發/測試，如果對於簡單的項目而言，用工具反而會效率下降，因爲就這麼幾行代碼，這麼幾個功能，一下子就可以弄好了，弄個工具反而浪費時間。
但是對於稍微大的項目而言，可能不用工具就沒法很好地管理項目了，比如說好了，一個團隊在一個迭代週期中做了10個功能，測試人員一天發現了40個Bug，但是修的人（由於部分人還在做功能）每天最多隻能修20個，那剩下的20個Bug怎麼辦，當然是延遲到下一天修了，一個迭代週期往往是一週到二週，假設兩週好了，如果每天都能多餘20個Bug的話，就累積了200個未修的Bug，假設沒有缺陷管理工具的話，我這些Bug可能只用Excel文檔管理一下，Excel對於單個用戶而言，保存信息其實做得很不錯，報表也很Ok，但是想想這麼多開發和測試需要打開同一個Excel文件，做查看，做更新，我相信Excel數據會被搞亂，而且Excel沒法做跟蹤，沒法設置流程，也就是比如說我想知道這個Bug經歷過幾個狀態，經歷過幾個人的處理，我應該是沒法找到的。
所以工具有用麼，我覺得還是有用，對於大中型項目，既然想用敏捷，我還是建議用工具，不然的話，這個敏捷最後肯定會變成不敏捷的。 就像乘坐公交車一樣，如果就是100米的路，我勸你還是走路（敏捷）算了，因爲公交車還要起步、停車和等紅綠燈了，也許你走得都比它快；如果是10公里的路，您當然會選擇公交車（工具）。對於敏捷而言，因爲是有很多迭代週期組成，每個迭代週期其實相當於一個100米，但是很多迭代週期組合在一起就變成了10公里了。真正的敏捷，它只是一種指導思想，沒規定你必須怎麼做（也就出現各式各樣的實現方式），所以，在正常的工作中，我們需要根據每個公司的實際情況來搭配符合你們實際情況的敏捷模式。
大家在百度上，只要搜索“敏捷測試”，我相信可以找到一大堆的內容，有概要的，有詳細的，仔細看看，大家會發現很多人認爲敏捷肯定是這樣子的，那樣子是不對的，當然大家對於“這樣子“的描述又都不是太相同，分析一下，無非就是兩種原因，一種純粹是自己瞎想的，可能稍微有點底子，但是沒實際用過，就按自己的想法，亂分析一番；另外一種就是真正在用的，所以就用自己公司的情況來解釋一下敏捷。當然，我其實也是結合自己公司的情況在說敏捷，所以我不會苛求大家一定要採用我的理論，只是希望大家能從我的文章裏發現一點對你們來說有用的知識，那我就很開心了。
好了，閒話少說了，不管您有沒有理解爲什麼要用工具，我還是繼續下去了（有問題可以私聊）。
對於TechExcel的DevSuite，以前也介紹過，也一直用到現在，感覺挺好用，不過在這裏也不多介紹了，就給個圖和然後把我們會用到的產品做個交代，不然之後萬一提到某個產品，大家可能不知道是啥了。
其中對於敏捷測試而言，需要用到的主要是以下三個產品：
1. DevSpec：需求管理，用於測試人員（設計測試人員）檢查功能的設計
2. DevTrack：缺陷跟蹤管理，用於測試人員根據功能的設計文檔來進行測試與提交Bug，並且跟蹤Bug的進度。
3. DevTest：測試管理工具，用於管理測試用例，以及用測試用例來生成測試計劃並且實施測試（包括自動化測試）
這三個產品可以集成在一起用，也可以分開單獨用，當然我們是集成起來用的。
接下來我就按照測試的實際流程來介紹一下敏捷測試在我們公司的具體實現情況。
1. 需求設計階段：
我們公司也是開發產品的，主要是開發CRM方面的產品，和其他軟件企業也一樣，我們每個版本的發佈首先是需要先收集客戶需求開發相應功能、自己研發出新功能以及查看研究並超越競爭對手的功能。
這部分的工作主要是在DevSpec進行，DevSpec是主要用來管理需求和分配需求讓開發去開始做的，它會對每個功能（不管是客戶的，自己的，或者研究競爭對手得出的）新建一個條目項，每個條目都會有自己的屬性，包括標題，負責人，狀態等，反正你想加什麼屬性都可以自定義的。然後負責人登錄系統就可以看到分配給他的條目，他處理完了就必須把狀態改到下一個狀態，並且分配到適當的其他負責人。對於測試而言，我們設置有一個狀態叫做“測試審覈”狀態，一般一個需求點到了這個狀態，咱們設計測試人員就會去處理這個需求，處理的方式，一般就是從原始的文檔入手，去看看現在的設計是不是符合原始的文檔，如果有出入的話，他就會去和設計人員交流一下，然後把這個條目打回“需要重新設計”狀態，設計人員弄完就會重新更改狀態，最後測試人員審覈通過後，就可以進入“待開發“狀態了。
這裏強調一點，在這個階段，所謂的設計測試人員，並不一定必須是專職的，他可能是項目經理或者是其他人，但是他一定是一個有能力來判斷設計思路是否符合要求並且有權力讓設計人員重新去設計的人。
這就是需求設計階段，測試人員要做的事情。下面貼個DevSpec的圖作爲今天文章的結尾. （未完待續）
