「我」是如何做測試專案管理的

2021-09-11 14:07:01 字數 4894 閱讀 2899

帶專案差不多1個季度了,針對這一季度的工作做乙個總結,分析一下成長和遇到的問題,希望後面可以做的更好。

以下內容有自己的總結,也有參考蔡為東老師的步步為贏—軟體測試管理全程實踐。

專案內容:ios端專案

測試組主要工作職責:做好測試工作,以最少的人力、物力和cost產出符合需求、保障質量的產品。

測試專案管理主要內容:

專案就是一件事,那麼專案管理就是通過某種方式來做成這件事情。測試專案管理主要包含測試流程的制定、根據制定的測試流程,控制三方(包含需求方、開發方、測試方)工作進度、工作流程以及溝通等,最終保障產出需要的東西。

作為測試組長,站在這個角度上,對於測試管理的理解是什麼?

1、心態的轉變——從乙個初級工程師,到乙個中級工程師,是對自己手頭被分配的任務有了乙個更深入的認知和理解;再到測試組長,就需要完成從點到面的過渡,看問題需要有大局觀,需要把握整個專案,很多邊緣邊界的問題,以及互相牽扯的模組,互相有互動工作的團隊,都需要考慮到,對於你的思維的整體性、溝通的能力、考慮問題的全面性,以及多執行緒工作的能力,都會是乙個考驗。

2、構建測試體系——明確測試流程,該流程是各方都需要明確的,這樣協調工作起來才能有條不紊,主要是指:需要測試盡早介入;需要給測試留出時間和準備資源;軟體測試小組需要編寫正式的測試計畫和測試用例,並且需要做評審;管理好測試環境(保證測試環境的單一性,不受其他的影響,能夠盡快確認是問題並且能夠盡快定位問題);為提測版本做驗證測試(驗證測試就是從用例中挑選出最精簡的測試用例集合);測試正式開始前開發需要自測;測試正式開始前要做可接受性測試(即從用例中挑選出p0級別的,也就是本次提測內容的最主要功能實現),不滿足的打回;明確bug管理流程(包括需求bug——由產品提出;提測後功能性bug——由測試產出;在這個過程中只有測試有權利關閉bug,要及時三方對bug情況);測試組需要寫測試報告(目前為每天晚上針對當天的測試情況給出報告:包括提測情況、測試情況、bug情況、明日計畫;其中bug情況需要統計當日bug總數、當日修復bug數、各個模組的bug、嚴重bug數、reopen的bug數,這些資料主要是為版本發布後的專案覆盤做統計的;其中bug情況要針對當天的bug情況做乙個總體說明,嚴重bug亟待解決的需要重點標出,產品上的bug也要說明,請產品盡快跟進解決);專案發布後要做專案覆盤(當前我們主要是每個版本結束後,做一次專案總結,針對整個版本從需求到最終的發布階段的各種問題,以及解決方案,以及上一期遺留問題及解決情況等一一做說明和彙總,只有不斷總結和推進解決,才能夠讓整個專案組的情況越來越好)

組建測試團隊(該內容當前我並沒有做過,因為專案人員是由上面分配的,但是對組內人員確實要進行關心,你的真誠是基本)

編寫各種模板檔案(當前組內已經推廣建立起來的包含:開發的提測模板、測試的bug模板、開發的bugfix模板、測試報告的基本模板、測試總結的模板;當然各個版本都可以視情況進行專項調整;那麼沒有建立起來的包括:測試計畫,該內容在當前環境下因為是推進產品比較緊張,所以一直沒有做過,後期確實需要做出來:最主要是嚴禁開發提測晚,壓縮測試的時間)

搭建bug管理系統、測試用例管理系統,我們現在用的bug管理系統是bugzilla、測試用例管理系統是testlink,主要使用過程中感覺bugzilla比較好用,testlink的話就稍顯遜色,但目前還沒有發現更好用的,也許excel更好用,哈哈。(注:確實要有機會要自己搭建一下這兩個系統,這樣才有真正的實戰經驗啊!)

其實說到底,這些就是:人、流程、模板、以及對流程中的產出的管理。

3、關於測試計畫的編寫:測試計畫的編寫,我這裡確實有疏漏,因為一直沒怎麼做過,沒有很好的經驗,這些後期要逐漸補上來。

4、溝通,溝通其實就包含對內和對外兩種,對內又包含對上和對下,以及同級三種,對外又包含對開發、對產品、對總的負責leader

對內——對上:讓領導知道你在做什麼,及時溝通,有問題當然要自己掌握度,不能事無鉅細全部問領導如何處理,一般領導只喜歡做選擇題也不喜歡做問答題,你需要有自己的判斷,然後從中選擇一些你不好推動或者需要他出面,或者一些事情上首次處理無很多經驗的情況下,要及時跟領導溝通,告知當下情況,當然要說出你的解決方案或者你的見解,並在領導推進解決問題,或者他提出一些方案之後能夠盡快學**到自己身上;當然及時告知也是為了避免出現事後無法補救才打臉的情況,提前告知風險,提前預知情況,能夠有更好的心理準備。領導其實也是你的老師,要跟他多學**,不要怕,學**他的經驗,學**他處理事情的方式,並主動在一段工作時間之後進行個人匯報總結以及小組匯報總結,及時反饋和得到上級反饋,如此才能不斷進步,往更好的方向走。

對內——對下:要真誠;要有個人的能力和德行作為服眾的乙個基礎,所以要不斷學**、總結、提高個人工作能力;要開放和公平,營造出這樣的氛圍才能人心不失;要量才用人;要及時溝通;對於自己指導的學員,更要及時溝通,能夠讓學員從工作中學到東西;建立起整個組內的學**、創新意識和氛圍(這是我覺得需要做的,雖然當前專案太緊張,做的很不好,只是自己在之前不是組長時做過,但上任組長之後事情太多自己也擱置了,確實是需要調整)

對內——對同級:對同級也抱著學**的心態,多溝通,多聊多問,解自己的工作疑惑,也聽他人的五味雜陳,吸取經驗和教訓,儘量減少坑和彎路,哈哈。

對外——對開發:要實事求是,遇到問題就事論事,測試與開發可能經常會因為一些問題爭吵,但不要影響互相之間的合作,這是前提,否則將來的工作無法繼續開展;要盡快溝通:大多數情況下確實是應該直接找單人私下溝通,比如一些比較嚴重的問題(涉及到類似提測失敗、reopen率太高這樣的情況),讓此人了解自己的問題,但不可縱容,對這種情況的縱容就是對測試工作的阻礙;對一些嚴重問題,還需要找開發的上級領導溝通,讓他做到心中有數,也將自己的觀點和期望表達清楚,但一切都是建立更好的做好工作的基礎上;對一而再、再而三的出現嚴重問題的情況,需要嚴厲、嚴重、特別的提出來,如此才能夠推進一些改革和改進的更好推行,方便開發建立起流程,也是對測試工作的一種支援。

對外——對總的負責leader:定期彙總上報工作內容,目前是通過專案總結的方式來做的,這樣能讓最上面的leader知道問題在**,並盡快借力來推進很多問題的解決。

5、測試用例的編寫:用例的編寫最重要,用例考慮的詳盡、步驟清晰,關注多個不同方面,才能夠從多個方面發現問題。

組織編寫測試用例,流程主要分為以下幾步:

明確任務和進度

提供相關的資料和條件

全面深入理解軟體需求

編寫測試用例的概要(測試點)

做測試用例的評審

細化測試用例

對測試用例保持動態更新(一定要堅持做,並且要總結出易錯點,保證每次回歸時覆蓋到,並在之後的測試中關注類似的方面)

6、測試執行:執行階段需要明確責任,鼓勵機制,並建立起整個測試組都及時發現問題、跟進、推進自己名下問題解決的氛圍快速建立起來,不止是為了發現問題,最重要的是發現之後推進問題的解決;當然在測試組長的角度上,就需要同時做多項工作,需要自己做相關的部分測試工作,還需要及時跟進其他成員的測試情況(這裡定期的溝通、抽查和諮詢就很重要了),也需要對大家所報的bug有乙個大概的認知,能從bug的情況以及bug的趨勢上看出大概當前進行到什麼測試階段了

測試執行的安排也很重要,一般情況下重要的模組會分配給比較有經驗的人來做;如果人手不太緊張,可以大家一起做,其他新人能夠在這個過程中不斷像其他經驗豐富的人學**。

測試組長要閱讀每乙個bug,這個要求並不過分,這個當前卻做得很不好。

7、測試總結:測試總結很重要,包括專案整理的總結、個人的總結、小組的總結;做專案總結,是為了梳理整個過程,明確問題和找到原因,改進整個流程和推進專案狀態越來越好。

那麼乙個基本通用的模板如下:

測試小組的總結:

測試計畫執**況:看實際情況有麼有按照計畫執行,如果沒有,找出阻礙和原因,是否可解

bug庫分析:包括bug的有效率、各優先順序的bug所佔的比率、各模組的bug分布比率、測試工程師的bug發現率、bug的修復率、各階段發現的bug發現率、bug的生命週期

其實可以通過問自己n個方面的問題,來豐滿每次的總結:人員安排、時間安排、風險分析、測試執行、bug、溝通、專案管理、員工管理,這些方面的總結需要根據不同的提交物件進行不同方面的刪減和充實。

在自己帶專案的整個過程中目前為止遇到的問題?如何處理的?目前自己認為可能需要加強或者需要後續更加關注的內容?

1、目前為止遇到的問題及處理措施:

開發團隊遇到很多問題,因為對產品質量的認知不足導致不願意解決,甚至有問題但是無法立即定位原因的,會拖n個版本也不解決:通過郵件方式、通過會議說明、通過專案總結、通過每天的專案測試情況的匯報,通過各種方式說明,並明顯註明(需要告知開發負責人、開發組的上級leader),告知開發需要解決,並且需要組內指派人員單獨跟進,並關注跟進的結果

對開發團隊不斷出現bug反覆、提測質量不高的問題:乙個是態度問題,乙個是能力問題;能力問題也需要找開發負責人溝通,由開發負責人來按照各人的能力分配工作模組,或者開發組內自己制定其他措施等,測試這方就是要告知開發需要明確的提測模板(包含提測檔名、提測路徑、提測說明,提測說明中包含詳細的資訊:正式環境或測試環境等,提測模組,影響範圍、建議重點關注內容、修復bug)、提測標準(測試點提前準備好,給開發做自測,需要自測之後功能上無明顯bug才可提測);態度問題就是:多溝通、測試人員單獨找對應開發溝通,積極追自己名下的問題,將測試的情況及時反饋給開發負責人,讓開發負責人來督促他們及時解決問題,制定各種模板,包含提測模板、bugfix模板、bugreopen率統計及處理措施等

2、後續需要關注的問題:

把專案帶穩定,建立起乙個積極的團隊;具體的根據各人能力不同分派不同任務,讓組內成員都能夠工作舒心且有成就感,這一點很重要,也不好做到;個人能力的繼續提公升,包括測試基本知識及時補充和更新、測試技術的掌握、**能力的提高、自動化的推進

**:

如何做IT專案PoC測試

poc proof of concept 即概念驗證。通常是企業進行產品選型時或開展外部實施專案前,進行的一種產品或 商能力驗證工作。驗證內容 1 產品的功能。產品功能由企業提供,企業可以根據自己的需求提供功能清單,也可以通過與多家 商交流後,列出自己所需要的功能 2 產品的效能。效能指標也是由企業...

我是如何做知識付費的

對這個領域可能你了解過,也可能沒有了解過,沒關係,通過本課程的講解,或許對你有一些幫助。可能也有人會問,知識付費真的可以做嗎,我又適不適合去做呢?我可以告訴你,任何乙個行業,都可以通過知識付費來做一遍,而且,許多人已經依靠做知識付費每年收入過百萬,所以,不要質疑能不能做,行動起來才是真正要做的。課程...

google是如何做測試?(三 四)

在谷歌,質量不等於測試,是的,我確定在其他所有的公司也都是這樣。質量不是被測出來的 這句陳詞濫調是再正確不過的了。不管汽車製造還是 軟體開發,如果在最初的設計建造的時候就有問題,那它永遠都會有問題。試問任何一家曾經被迫大量召回汽車的公司,逃避質量問題的代價是多麼的昂貴。但是,質量不是被測出來的 這句...