- 相關推薦
如何管理測試團隊
以下是我為測試經(jīng)理提供的25條秘訣——如何收獲積極的測試團隊。
1. 學會聆聽。一般測試者更加清楚項目的重心。
2. 組建小分隊。人多注意力易分散。
3. 多思考。思考讓工作更高效。
4. 關于預期，應多考慮團隊的情緒。
5. 提出盡量多發(fā)展要并提供培訓。鼓勵團隊不斷學習與創(chuàng)新。
6. 不要自行解決程序錯誤。商量結果更佳。
7. 每天和隊員面對面交談（我稱之為“閑逛管理”）。
8. 詢問測試員每天最困難的挑戰(zhàn)。然后為他們做點什么。
9. 確保每位隊員都在為團隊做事。個人英雄是很危險的。
10. 相信并授權給你的團隊。你是請他們來干活的，那就放開手讓他們干。
11. 分類各種會議，讓大家知道會議的目的（太多會議了）。
12. 年假請求照批不誤。項目進度總是會落后于計劃的，而大家都需要假期。
13. 計劃進度應自行把握，不可受他人影響。
14. “門戶開放政策”——確保你隨時可以和任何隊員交談。
15. 慶祝團隊的成績而非個人成績——考查個人留待年終評估。
16. 承擔責任，分享成功。
17. 建立積極的氛圍。總是否定會產(chǎn)生負面影響。
18. 責任到人。每個人都要學會負責任。
19. 隊員每天自評（10分滿分）。此舉可讓他們記住自己每天所作所為，并客觀評價。你也可以和他們分享自評分數(shù)。
20. 建立伙伴互助系統(tǒng)。有問題，分享解決良策。
21. 確保團隊的所有任務都是你個人可以解決的。要設身處地為隊員。
22. 不要害怕求助。你不可能知道所有的事情。
23. 并不是所有人都可以公開地發(fā)表意見——理解、接受內向者。
24. 每周至少一次團隊活動，即使只是一起喝喝茶、喝喝咖啡。
25. 盡可能多笑。不要憂愁，保持樂觀的心態(tài)。
最后，我想對閱讀了這篇文章的測試組員說：如果你的測試經(jīng)理沒有做到以上的某些或全部，不要過分苛責他們。他們也是凡人，要相信他們也在盡自己最大的努力改變。我們都應該讓自己每天前進一點。
如何管理自己的測試團隊
1、作為一個團隊的管理者，最起碼的是要自己懂自己產(chǎn)品或項目的業(yè)務。這一點很重要，第一這樣有助自己分配工作給團隊中的成員，要不然自己都搞不清楚業(yè)務難度和業(yè)量就分配工作給team member是件很讓人難以接受的事情。第二，有助于自己和其它team或department的合作和溝通，不至于其它team提出的問題，自己還不清楚就答應或否定要做。
2、作為一個管理者，要懂更多的技術，至少是了解更多的測試技術，要了解其工作原理，這樣有助于自己幫助團隊成員research或者說技術的應用到實際的測試工作中來。也可以提高自己在測試團隊中的威性，自己懂得多能讓更多的同學認可和信服。
3、平衡按特長分配工作任務給team member。對于senior的測試員我們分配更多的任務是design test case的，junior的測試員可能更多的是分配執(zhí)行測試。分配工作也是看看哪位測試員的特長，有些測試員對GUI比較敏感，有些測試員對Logic比較關注，有些測試員對整個系統(tǒng)的流程更清楚，這些都是作為測試管理者分配任務的一個基線，這樣可以更好地帶好一個團隊，提高軟件測試的水平和質量。
4、做好測試風險的管理。一般來說我們要盡可能降低測試風險，也是測試管理中一個很重要的課題，我也只能講講自己的一些片面的觀點。
測試風險從軟件需求分析開始就存在，我們要更好地在前期發(fā)現(xiàn)這些潛伏在需求或開發(fā)設計中的風險：1）如需求提出無法達到的功能，或有違背現(xiàn)有功能的需求我們在需求分析時一定要提出來；2）軟件需求設計中的有些無法測試的功能或要點，也要在測試需求分析中提出來；3）開發(fā)設計文檔的靜態(tài)測試，這一點我覺得很重要，很多小公司基本上會忽略這一點，靜態(tài)測試（主要是指文檔方面的測試），對開發(fā)設計文檔或原型設計文檔的Review或測試有助于測試風險的降低，也能發(fā)現(xiàn)一些與需求沖突的設計，爭取錯誤在前期發(fā)現(xiàn)。同時我們測試用例在測試方面也可以更好地與其配合，設計更好的的測試用例去測試，無論是從GUI，還是開發(fā)測試技術上測試都是有益的；4.對測試用例的Review或靜態(tài)測試，這樣有利于優(yōu)化測試用例，補充更多有用的測試用例和除去一些無用或重復的用例，這樣能提高測試執(zhí)行效率。5.監(jiān)測測試執(zhí)行及bug管理，Bug算是測試員的成果之一，我們作為管理者一定要管理好，同時也能讓我們清楚看到測試風險的存在，可以通過現(xiàn)有的Bug趨勢判斷系統(tǒng)中未來還有多少bug存在，可以通過bug的類型分析fix bug還要多長時間還可能會產(chǎn)生多少bug。
這樣我們就能清楚知道當前測試人員和開發(fā)人員什么時候哪些人要開始加班了或要加派人手了...，我們還要關注測試執(zhí)行進度，測試執(zhí)行初期bug趨勢圖，哪些類型的bug多些，此時會不會影響到測試中期，Logic的bug多的話一定會影響到測試中期的質量和測試效率的，此時要提醒開發(fā)團隊要注意logic類型bug的fix，不能把這類bug拖到后期fix，這樣會影響質量。
當然軟件質量風險還有其它的因素影響，如項目或產(chǎn)品時間評估，我想這部分大多是硬性的，我們可以協(xié)商測試的項目時間；還有人員請假或離職，以及測試組人員的變動，還有測試人員情緒波動都會影響到測試質量風險的。
5、合理評估測或衡量測試人員的績效和水平。相信這一點也是很難做到的一點，做得不好，不僅無法讓整個團隊好好工作，內部矛盾多，造成員工離職都會有，是讓一個團隊最頭痛的事情，那么我們如何合理評估測試人員的工作呢？首先我覺得公開硬性績效標準，讓大家都明白一個標準，也是團隊共同發(fā)展的目的，這樣做到公正，不會有私心。
我覺得我們可以從幾個方面去衡量：a）工作態(tài)度及積極性 b）工作量和工作質量的一個線性比較，工作量大的一定是最辛苦的，但要與其工作質量作參考的，當然我們不能把一個員工發(fā)現(xiàn)的Bug量作為其工作成績好壞的標準，我記得以前一位測試經(jīng)理就是這么做的，這是很要命和害了整個公司的做法，因為測試的對象不同或開發(fā)人員水平不一樣及項目大小和難易程度，都是影響bug數(shù)量是不一樣的因素，我覺得一個比較好的標準是從中多方面來看的，測試執(zhí)行過程和測試用例兩方面，執(zhí)行測試過程中bug趨勢圖和bug類型分布圖及軟件交付后bug反饋率，測試員應在測試執(zhí)行過程中發(fā)現(xiàn)各階段中應當發(fā)現(xiàn)的bug，不能說很明顯的bug而在最后才發(fā)現(xiàn)，這些都可以看出測試員的水平；另外測試用例的設計也是一個很重要的標準，很好的測試用例，會盡可能早地發(fā)現(xiàn)bug，當然測試用例的設計可操作性、詳細度等都是衡量的標準。
6、凝聚團隊和激發(fā)團隊成員的潛力。這一點，雖說是有點大話，但真的也是很重要的，我覺得很重要的一點就是讓團隊中的每一個人都在成長，安排合理的工作角色很重要，讓他們能更好的看到自己的成長空間，如讓比較junior的測試員設計比較簡單的測試項目或需求的測試用例，這樣讓他也覺得自己也能設計測試用例；讓很Senior的測試員負責項目，讓他覺得是項目中的主角而不是測試經(jīng)理的身影，這樣讓團隊中的成員也會更有責任心；安排比較空閑的測試去Research更新的技術或測試技巧并通過講課的形勢分享給所有的成員；在項目執(zhí)行中，安排測試員在執(zhí)行這程中去交換測試，這樣可以讓參與這個項目的成員對整個系統(tǒng)了解，這樣項目的每一部分都相當于有backup人員，不擔心項目哪位請假而為難了，也培養(yǎng)了測試人員的業(yè)務知識。多多讓成員之間溝通，一起參加工作之外的活動。
7、溝通成員，了解成員的心態(tài)。作為一個管理者要多多關心成員的心態(tài)問題和成長問題，為什么工作不太積極？為什么項目質量不高？....都可以通過私下聊天談心來了解，并幫助他們解決！
【如何管理測試團隊】相關文章：
如何建設與管理團隊05-10
管理者如何融入新團隊06-06
如何描述創(chuàng)業(yè)團隊05-18
如何打造創(chuàng)業(yè)團隊05-18
如何加入創(chuàng)業(yè)團隊05-18
如何建設創(chuàng)業(yè)團隊05-18
如何創(chuàng)業(yè)團隊分工05-18
如何組成創(chuàng)業(yè)團隊06-01
如何搭建創(chuàng)業(yè)團隊05-18