qileilove

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

          軟件測試管理與組織結構

           一個測試管理者在考慮提升組織的測試能力、進行一系列測試改進時,除了考慮測試技術本身的因素外,還有一項不能忽略,那就是測試的組織結構。

            《TPI Next》里面劃分測試關鍵域時,專門單獨劃分了一個“test organization”的key area,并且定義“A test organization meets the needs of projects for test resources, test products and test services.”,認為測試組織就是關于“the right people expertise and experience at the right place.”的事情。 本文探討的測試的組織結構只是“test organization”的一部分,重點探討測試的組織結構如何與開發的組織結構相對應的問題,基本上對應TPI里的controlled level,即“A test organization enables uniformity in test approach, test products and procedures, agreements and clear test results.”

            為什么 談測試管理時,要談測試的組織結構?其實,組織結構在有關測試管理的探討中有著不可忽視的作用,它體現著管理思想,也反過來對測試管理有輔助的作用,這就 像經濟基礎決定上層建筑一樣,測試管理理念達到了什么層次,就會制定相應的測試組織結構,以更好的落實這個理念。實踐證明,很多測試過程中出現的問題最后 都與組織結構有關系。

            而談到測試的組織結構時,勢必要先參考開發的組織結構。對于傳統的瀑布開發模式而言,一個系統有可能會劃分為幾個模塊來實現,開發的組織結構基本上是和模塊一一對應的,我們就拿這種典型的情況討論一下相應的測試組織結構應該如何劃分。

            一個產品的開發可以分解為多個模塊來實現,這個產品的某個功能或特性經常需要多個模塊配合實現。假如每個模塊對應一個開發項目組,測試項目組的劃分經常會有兩種選擇,一是也按照模塊劃分,二是按照特性劃分,一個特性可以跨多個模塊。那么二者各有什么優缺點呢?

             按照模塊劃分的測試項目組,由于和開發項目組存在一一對應的關系,二者關系更為緊密,開發人員和測試人員的交流也更為順暢,會經常一起探討模塊級的細節 和實現,有利于在產品開發階段(發布給測試前)測試人員的前期介入,這種前期介入包含很多方面,例如測試人員對設計文檔的評審檢視、測試分析與設計的分工 合作、測試人員參與的前期代碼走讀、集成測試等等,更多地測試前期介入的內容可參考這篇blog。 因此,按照模塊劃分的測試組織對模塊會進行比較充分的測試,但這種模式也存在一些弊端,比如對于涉及到多個模塊的特性,測試人員在測試分析設計和評審檢視 中往往考慮欠佳,測試人員對整個系統層面的把握不是很到位,同時測試人員和開發人員的過于“親密”也造成測試無法扮好“黑臉”的角色。

             按照特性劃分的測試項目組,對上述弊端可以做到較好的規避。但這個時候常常是測試為了避免受開發思路的太多影響,獨立彰顯測試的價值,從測試設計到測試執 行都會另起一套,更多的從測試的角度、從客戶的角度考慮問題,更多的站在特性一級、系統一級考慮問題,測試在把系統當作一個黑盒進行系統測試方 面越來越擅長,此時的測試管理者如果不注意把握一個“度”的話,就會出現“測試后移”的現象,測試人員把眼光聚焦在后端,致力于問題發現,漸漸的,代碼走 讀、集成測試等前端測試的活動測試做的偏少了,甚至都移交給了開發人員。可是開發人員“天生”的對問題不敏感,其質量難以保證,很多開發人員認為開發人員 所做的測試“測不徹底”是很正常的事,反正后面有測試人員做后盾。那么時間長了,這種模式的弊端也會逐漸暴露:純黑盒的系統測試周期拉得很長,因為缺陷遲 遲不能收斂,開發在版本轉測試后也疲于奔命修改問題單使得人力遲遲無法釋放;如果產品的需求控制不好的話,新需求的不斷合入會加劇問題的惡化,新需求將無 法得到有效跟蹤、設計和驗證;很多本應該在UT、IT發現的問題都遺留到了系統測試階段,測試部為了保證產品的質量,花費大部分時間驗證這些前期遺漏的問 題,而沒有精力站在客戶角度、從組網場景、應用場景開展對需求的系統級驗證,導致問題在網上頻頻爆發;而如果測試人員穩定度不高時,測試人員的不斷更新, 會導致了解系統內部實現的測試人員越來越少,隨著產品的快速更新演進(對比較復雜的產品而言),測試人員在系統架構層面的討論上顯得力不從心,等等。

            那么究竟應該選擇什么樣的組織結構才會最大化測試效率呢?答案是沒有定論。這要結合開發的組織結構、開發模式、測試人員構成、產品復雜度、需求穩定度、組織的測試經驗積累、當前產品的軟肋是模塊還是系統等因素綜合考慮。

            但是至少有兩點是可以確定的:

            1)上述兩類典型的測試組織結構無論選取哪一種,都與測試組織的成熟度沒有必然的關系;

            2)無論選取上述的哪一種,甚或是第三種、第四種,組織結構都不是一成不變的。實際上,有的組織會經常在這兩種組織結構形式之間來回變換,以適應不同的歷史形勢。

          posted on 2013-01-10 13:43 順其自然EVO 閱讀(230) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2013年1月>
          303112345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 辛集市| 广水市| 茂名市| 水城县| 荣昌县| 东乌珠穆沁旗| 翼城县| 平乐县| 岚皋县| 肥乡县| 睢宁县| 黄平县| 泌阳县| 金寨县| 文水县| 潞西市| 广东省| 红河县| 慈溪市| 林西县| 墨竹工卡县| 师宗县| 安乡县| 页游| 柞水县| 全州县| 克东县| 丁青县| 饶河县| 南溪县| 连南| 黎川县| 榆林市| 虹口区| 汝南县| 册亨县| 敦煌市| 德江县| 昭通市| 乡城县| 且末县|