qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          敏捷測試理論以及實踐(5)

           以前在《結合工具來實現敏捷開發》這篇文章中,我已經談到了我們公司目前的開發情況,在這里也不再重復介紹了,反正主要就是用 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:需求管理,用于測試人員(設計測試人員)檢查功能的設計

          3、DevTest:測試管理工具,用于管理測試用例,以及用測試用例來生成測試計劃并且實施測試(包括自動化測試)

            這三個產品可以集成在一起用,也可以分開單獨用,當然我們是集成起來用的。

            接下來我就按照測試的實際流程來介紹一下敏捷測試在我們公司的具體實現情況。

            1、需求設計階段:

            我們公司也是開發產品的,主要是開發CRM方面的產品,和其他軟件企業也一樣,我們每個版本的發布首先是需要先收集客戶需求開發相應功能、自己研發出新功能以及查看研究并超越競爭對手的功能。

            這部分的工作主要是在DevSpec進行,DevSpec是主要用來管理需求和分配需求讓開發去開始做的,它會對每個功能(不管是客戶的,自己的,或者研究競爭對手得出的)新建一個條目項,每個條目都會有自己的屬性,包括標題,負責人,狀態等,反正你想加什么屬性都可以自定義的。然后負責人登錄系統就可以看到分配給他的條目,他處理完了就必須把狀態改到下一個狀態,并且分配到適當的其他負責人。對于測試而言,我們設置有一個狀態叫做“測試審核”狀態,一般一個需求點到了這個狀態,咱們設計測試人員就會去處理這個需求,處理的方式,一般就是從原始的文檔入手,去看看現在的設計是不是符合原始的文檔,如果有出入的話,他就會去和設計人員交流一下,然后把這個條目打回“需要重新設計”狀態,設計人員弄完就會重新更改狀態,最后測試人員審核通過后,就可以進入“待開發“狀態了。

            這里強調一點,在這個階段,所謂的設計測試人員,并不一定必須是專職的,他可能是項目經理或者是其他人,但是他一定是一個有能力來判斷設計思路是否符合要求并且有權力讓設計人員重新去設計的人。

            這就是需求設計階段,測試人員要做的事情。下面貼個DevSpec的圖作為今天文章的結尾。(未完待續)

          posted on 2011-11-18 14:56 順其自然EVO 閱讀(153) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2011年11月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 沅陵县| 赤壁市| 伊金霍洛旗| 天水市| 尉氏县| 庆安县| 广宁县| 双城市| 花垣县| 香港 | 长丰县| 报价| 吉水县| 永胜县| 清徐县| 巴林右旗| 绥棱县| 郑州市| 安化县| 东明县| 寿宁县| 富阳市| 定远县| 漳州市| 乌拉特中旗| 呼玛县| 台中县| 澄城县| 宕昌县| 电白县| 满洲里市| 兴义市| 闽侯县| 麦盖提县| 永丰县| 黄陵县| 兴和县| 成武县| 乐至县| 镇安县| 乾安县|