新手測試經(jīng)理如何規(guī)范測試團隊（測試管理篇）

當你來到一個項目不規(guī)范的技術(shù)團隊，你會怎么處理呢？

沒有需求評審和設計評審，需求經(jīng)常是業(yè)務或者項目經(jīng)理直接跟開發(fā)提，有時候開發(fā)自己都不明白需求，糊里糊涂地就要開發(fā)，也沒有設計評審，開發(fā)想怎么設計就怎么設計，代碼質(zhì)量差。

有時候下游或者上游開發(fā)并沒有接到需求，然后這邊開發(fā)完給到測試，測試也一臉懵逼。

上線時間不是根據(jù)開發(fā)和測試同學排期和評估來定，而是業(yè)務和項目經(jīng)理說了算。

開發(fā)完了就跟測試同學說一聲，有這么個需求，這個需求今晚/這周上線，你測一下，好像測試是個很隨意的工作，并且每個任務給過來都說是緊急需求，測試時間也是不夠的，導致測試非常被動。

很多時候沒有需求評審，測試同學連業(yè)務是誰都不知道，經(jīng)常是基于開發(fā)的講解進行測試，寫不寫測試用例也是看自己習慣了，開發(fā)同學也不清楚測試同學要測什么，畢竟也沒有時間進行測試用例評審(也沒有人負責安排)。

沒有每日站會和每周站會，開發(fā)和測試同學不會主動反饋進度和風險，即使是當前進度不理想的項目大家也都不提，即使要上線了沒測完也不管，反正上線就完事，有時候項目經(jīng)理會追問測試進度。

所有的測試環(huán)境信息、數(shù)據(jù)庫表字段信息、業(yè)務說明都是每個人自己保存著自己要用的，大家都不去維護一份公共文檔。

項目完成之后沒有總結(jié)，出了線上問題大家也不會復盤，無論開發(fā)還是測試都沒有整理業(yè)務文檔、記錄項目的習慣。

總而言之，就是十二分不規(guī)范。他們可能覺得，本來就夠忙了，花時間整這些東西，不是更忙了嗎。

殊不知因為流程的不規(guī)范，帶來的是更低的研發(fā)效率和研發(fā)質(zhì)量。遇到這些問題，可以從哪些方面進行改進呢？

可以在一份共享表格中維護，可以是在一塊白板里用便利貼跟進，列出目前開發(fā)中的、已提測待測試的、測試中的、已完成的任務，并且標明計劃提測時間、實際提測時間、計劃上線時間等信息，方便管理測試計劃和測試進度。

中大型項目在開發(fā)之前需要有技術(shù)評審，各端開發(fā)都需要參與，盡量避免由一個人決定怎么開發(fā)就怎么來。

達到提測標準時需要發(fā)送提測郵件給測試同學，說明改動范圍、影響點、自測情況、單元測試覆蓋率等。

中大型需求需要在測試前進行測試用例評審，相關(guān)的產(chǎn)品和開發(fā)都需要參與。

溝通需求時，測試同學可以將需求用各種形式表現(xiàn)，便于產(chǎn)品、開發(fā)之間溝通和確認細節(jié)。

梳理流程圖：復雜的交互可以畫流程圖，方便后面的測試同學理解需求。

如果是由幾個測試同學跟進的大需求，在大家看了需求文檔之后安排個小會議室，大家一起頭腦風暴一下，由一個人先主講整個過程，然后其他同學進行補充和提問，達到快速學習和掌握需求的效果。

如果是時間緊迫的需求，可以幾個測試同學到一個小會議室，結(jié)合代碼改動點快速確認當前實現(xiàn)是否符合目標，是否有邏輯問題，然后結(jié)合需求和改動點快速梳理測試點。

公共點整理：各個重要的模塊注意事項和踩坑點匯總成一份各模塊checklist，下次測該模塊的同學就能盡量少踩坑。

總之，就是發(fā)揮主觀能動性，有什么好的實踐可以幫助提升測試質(zhì)量和提高測試效率，就可以去做，最重要的是及時溝通。

每個月測試組內(nèi)做一次總結(jié)，可以分享典型問題，可以提出一些大家覺得待改進的點，也可以隨意吐槽。最后將大家提出的點整理好推動落地。

大項目上線后，組織相關(guān)同學進行總結(jié)，每個人分享覺得自己做得好和做的不好的地方，總結(jié)可以改進的點并推動落地。

在月度總結(jié)里一起，需要大家提前將各自要分享的問題記錄到統(tǒng)一地方，可以是測試中遇到的典型問題或者線上產(chǎn)生的問題。

一般需求上線后第二天比較空閑，這是整理業(yè)務文檔的好機會，可以整理業(yè)務流程，或者相關(guān)的sql、操作文檔、腳本等。

每周一個同學在組內(nèi)做業(yè)務分享，可以不需要準備ppt，直接在白板上畫，可以分享自己熟悉的一個業(yè)務，或者是這周接手的一個業(yè)務需求，達到組內(nèi)知識共享的效果。

可能有同學會奇怪，為什么都是這么基礎這么普通的東西，為什么不做自動化提升效率。

一是自動化并不是解決所有問題的萬金油，為什么要自動化，當然是到手工測試效率阻塞測試進度的階段，才需要通過自動化提升測試效率。

而想要提升效率，應該是先文檔化，將知識沉淀下來，然后是腳本化，將重復性的工作自動化，最后是結(jié)合基礎腳本實現(xiàn)平臺化。

一上來啥也不管就想用自動化測試平臺完成自己的KPI并不是一個理智的想法。

二是，我認為組織目標是要基于當前的矛盾的，每個階段有每個階段的矛盾，每個團隊當前面臨的問題不同，比如需求不清晰、 測試環(huán)境不夠用、測試環(huán)境不穩(wěn)定、造數(shù)據(jù)效率太低啦等等。

那么我們要做的就是基于這些問題一個個推進解決。所以不是在任何情況下都是測試框架測試平臺才顯得高大上，特別是面對流程不規(guī)范的團隊，把這些基礎的流程做好，就能大大提升大家的工作效率了。