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