qileilove

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

          我的軟件測試之旅:(10)貢獻——開發項流程

            開發項流程(Development Item Process)

            當時的這個Scrum試點項目身負重任,其中之一就是要探索出在新型的敏捷模式下該使用何種的開 發流程,負責人就是當時的Linux部門經理,而我則撈到了負責測試部分流程的機會。整個試點項目的人員擴張速度不錯,4個人的團隊維持了好幾個迭代,陸續有人加入,新的測試人員在大概是第四個迭代的時候才補充進來,而后逐漸擴張到兩三個團隊。這樣的擴張速度對測試流程的確定來說非常好,一開始我可以只考慮自己的想法,不斷地嘗試摸索,可以很快地得到反饋然后改進;等到想法大致成形的時候,又可以專注于幫助其他成員理解流程和使用,驗證流程的易用性;等到人員更多的時候,就可以著重驗證流程的推廣復用性。

            試點項目并非是全權負責新產品的開發,它其實是歸屬一個更大的項目、產品的,產品經理在芬蘭,芬蘭也還有一些團隊,兩地之間的團隊必須要合作,雖然杭州的項目享有流程等各方面的自由,但也必須考慮和芬蘭團隊現有模式流程協作的問題。流程中也要把這些細節都考慮進去。

            我討厭浪費,討厭重復的信息,也不喜歡把不同特點的信息混淆在一起,而且流程要為人服務,它需要根據人在工作中的行為、活動特點來制定,而不是憑空想象,這是我在流程總結中所秉持的重要原則。因此,在流程中測試活動開展所需要的信息,每一份信息只應該存在于一個位置,其他地方全部應該通過鏈接或者引用使用這些信息,而且測試和開發都會用到的信息也適用此原則。信息應該分為長期存在和短期存在兩種,可以看做是從讀、寫的角度進行區分:同一份信息和被測對象相關,且在可預見的未來還會繼續被讀寫的話,看做是長期的類型;同一份信息主要是階段性的,和特定的版本、時間點相關的,且在可預見的未來只會被讀取但不會被更新(寫)的,看做是短期的類型。兩類信息或者以不同的文檔進行維護,或者以不同的方式進行維護。

            如下簡單表述一下當時所設計出來的流程,這個流程因為種種原因在試點項目結束后沒有被延續使用,但是大概是三四年后我已經成為敏捷教練的時候,意外得知它居然一直在別的產品線沿用至今(當時),其生命力可見一斑。我將側重描述其變化、改進之處,和以往流程相同的地方則不做介紹。

            ● 新流程的目標包括:推動開發和測試專家們的密切合作以提高軟件的質量;合理化以及簡化相關文檔;減少文檔數量,加強維護,以提高文檔的質量;促進開發和測試人員之間的互相學習,以增加項目資源的靈活性;等等。

            ● 開發項是新提出的概念,將軟件的規格說明書撰寫、設計、實現和測試封裝在一起,作為最小的原子化產品組件(Component)。原子化的意思是保持開發項之間的互相依賴在可以做到的最低水平;移除或重排任何開發項的時候,對其他開發項不產生(或產生最小的)影響。

            ● 在迭代開始前,先有技術報告或者需求文檔,由此而產生出開發項;然后是和以往的項目過程一樣的入口階段,確定項目日程并且生成相關的高階(High Level)文檔。包括集成計劃文檔、項目計劃文檔、模塊(Module)測試策略以及開發項測試計劃文檔都在此時創建。

            ● 所有和開發項相關的測試活動都在Sprint內完成,這些測試被稱之為DIT(開發項測試),測試用例本身還是屬于以往的功能測試級別。但是開發項的測試計劃、測試執行、報告等一系列過程全部都要在一個Sprint中完成,測試用例的自動化比例并未做硬性規定,但當時我們的成果是100%自動化。

            ● 項目成員主要分為開發和測試兩類工程師,但是角色的定義并不是拿來當做不可逾越的紅線使用,必要的情況下,開發工程師也會承擔部分測試任務甚至整個人投入測試,或者測試工程師也會和開發工程師一起,結對開發代碼。

            ● 開發人員的工作安排會受到測試工作的影響,每日站會或者平時工作中,可能會發現軟件不容易測試,就需要開發人員協助檢查以及修改代碼提高軟件的可測性。或者是在開始寫測試腳本之前,就去跟開發人員約定程序輸出的內容和格式。

            ● 測試文檔根據信息的長期性、短期性進行了區分。

            1、測試計劃與報告:將這兩個單獨的文檔合并到一起,在單獨的章節里展示各自的信息,每個軟件發布使用一份測試計劃和報告。總共四個章節:被測功能描述以及模塊列表(持續更新)、持續集成測試狀態(每個迭代的測試報告)、總結(質量評估、經驗反饋、推薦和建議)、現存問題(尚未解決或仍不明晰的問題)。目的是在單個軟件發布周期內持續記錄測試的狀態,縮減不必要的文檔量。

            2、測試用例與缺陷:每一個模塊或技術領域使用一份測試用例及缺陷文檔。文檔內容包括:該模塊或技術領域的整體描述,測試用例列表及狀態,缺陷列表,測試輔助程序,操作命令。目的是提供一份可以全面了解被測模塊或技術領域的文檔,包括當前的所有功能、曾有的和現存的缺陷,以及如何使用操作命令和測試輔助程序進行測試。

            3、測試用例清單:用Excel記錄所有的測試用例即可,信息來自于現有的測試管理系統,包括測試用例的編號、已測過的最新軟件發布、已測過的最新版本信息、測試用例的版本、測試用例名稱、自動化的狀態。

            4、缺陷清單:用Excel記錄所有的缺陷即可,信息來自于現有的缺陷追蹤系統,包括缺陷的編號、標題、嚴重程度、缺陷單狀態、相關的測試用例以及版本。目的是提供一目了然的缺陷清單,可以知曉其歷史及現狀。

            5、Sprint缺陷清單:記錄在Sprint開發過程中發現的軟件缺陷,相當于輕量級的缺陷追蹤系統,無法當天修復的問題才會被記錄下來,而無法在當前Sprint中解決的問題則會被錄入缺陷追蹤系統,并且錄入前一個缺陷清單。

            Linux編程培訓

            為了幫助新人快速地融入項目,我們還承擔著開發一套培訓課程的任務。在Linux環境下進行開發的同時,我們需要總結經驗,有針對性地記錄所需要掌握的各方面知識,并且做成培訓材料,提供給加入團隊、項目的新手。我也參與其中有少量的貢獻。

          相關鏈接:

          我的軟件測試之旅:(1)起點——作為軟件開發人員

          我的軟件測試之旅:(2)轉變——作為專職測試人員

          我的軟件測試之旅:(3)同期——加入測試自動化小組

          我的軟件測試之旅:(4)并行——自動化回歸測試

          我的軟件測試之旅:(5)難點——功能改進的測試

          我的軟件測試之旅:(6)跳轉——追逐新鮮事物的探險者

          我的軟件測試之旅:(7)啟程——Scrum中的測試工作者

          我的軟件測試之旅:(8)困難——沒有現成的測試工具

          我的軟件測試之旅:(9)行動——簡化測試文檔和流程

          posted on 2012-08-09 10:10 順其自然EVO 閱讀(254) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2012年8月>
          2930311234
          567891011
          12131415161718
          19202122232425
          2627282930311
          2345678

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 崇义县| 仙游县| 仪陇县| 黄大仙区| 祁门县| 正宁县| 永新县| 晴隆县| 沁源县| 虞城县| 遵义市| 青龙| 石狮市| 连城县| 大洼县| 鄂伦春自治旗| 凌源市| 岐山县| 万宁市| 浦北县| 宜城市| 阿勒泰市| 勐海县| 桐庐县| 金昌市| 菏泽市| 保亭| 蓬安县| 论坛| 新安县| 黄龙县| 新干县| 武川县| 怀安县| 商水县| 磴口县| 秭归县| 华池县| 孝昌县| 兴海县| 上杭县|