我是一名測試經理,在過去的兩年時間作了兩件事,團隊從0到1的搭建和從QC到QA轉型。這兩年沒有什麼精彩的故事,都是一次次的嘗試-失敗-嘗試的過程。工具
公司背景
近兩年主要作項目外包。客戶是央企,咱們作完的項目要過他們的測試部驗收,測試超過兩輪要罰款。他們經過的標準是通常問題不超過三個,輕微問題不超過五個。測試
第一次失敗——冒進的左移
團隊組建後,我等到了第一個全新的項目A。這個項目對我和個人團隊來講都是相當重要的,咱們須要這個項目來給本身樹個標杆,開個好頭。
因而我把過去兩年我認爲最有效的測試方案應用到項目-測試左移。在項目經理的配合下,咱們將項目按模塊進行了拆分,並配合着制定了開發計劃和測試計劃,一切都有條不紊的進展着。隨着項目的推動,一個致命的問題暴露了出來——返工。大量的工做被推翻重作,項目週期也延遲了一個多月。在這一個多月中,測試和開發團隊都在不斷的返工中度過。項目最後的交付質量也是慘淡收場——驗收五輪。
項目結束後,我反思了失敗的緣由:spa
1. 測試方案的激進: 在對項目的總體難度和項目團隊能力有充分認知前,貿然的選擇了最激進的左移,導致測試工做節奏混亂,在後期的不斷返工過程當中,成員情緒也有很大的影響。
2. 里程碑拆分不科學: 在開發計劃制定好以後,匹配測試計劃時,單純的只考慮了完成了哪些就測試哪些。徹底沒有考慮到模塊間耦合的問題,沒有考慮後面開發和修改bug對已完成工做的影響,也是形成返工做主要緣由。
3. 變動失控: 這個項目的需求前先後後修訂了幾十版,一部分是客戶頻繁的提出新的要求,另外一部分是由於在項目進行過程當中本身發現的的坑,不得不一次一次的填坑。變動失控,勢必形成無休止的返工和延期。
4. 低估了項目難度: 項目初期測試針對項目數據方面的邏輯設計了數據模型,可是隨着項目的不斷深刻,測試和開發達成的一致被不斷的推翻,甚至在最後交付前,核心的數據邏輯測試和開發還發現有部分分歧。設計
錯過了兩次補救的機會接口
總結:開發
第二次失敗——不靈活的「靈活」文檔
團隊組建之初,項目並行是咱們面臨的一個巨大的考驗。因而在項目B上,我嘗試了團隊的靈活切入切出,但願實現人員的可插拔。
在項目B中,每一個階段開發完成我都會嘗試更換一名測試人員,但願鍛鍊團隊面對項目時的靈活性。項目B前先後後參與的測試人員有5名,最後的交付質量一樣是五輪驗收。
又是熟悉是場景,卻有不一樣的緣由:產品
1. 項目盲區: 人員變動勢必形成對項目和需求的盲區,每一個人負責本身的階段和模塊,即便多作一些,仍然不足以覆蓋到整個項目的盲區,盲區就Bug的溫牀;
2. 人人負責=沒人負責: 當全部參與項目人都知道我只會在項目中工做一小段時間,當要求全部參與項目的人對項目負責的時候,就是沒人會對項目負責;
3. 測試工做很失敗: 在對客戶驗收的問題作總體分析以後,發現75%的問題是由於咱們對客戶驗收標準的不對齊致使的,如兼容性要求,需求文檔要求,用戶場景要求等,都被咱們忽略掉了。it
總結:基礎
第三次失敗——成本纔是王道
公司的項目所有都是功能測試,本着提高團隊素質和產品質量的初衷,開始推動接口測試。在給團隊作了兩期的基礎概念加工具使用的培訓以後,找到項目經理選定了一個週期相對寬鬆的項目開始了接口測試之旅。過程總體符合預期,兩週的時間完成了用例設計到測試的所有內容。發現了一些項目問題,團隊也積累了實戰經驗。可是仍是失敗了,此次失敗不是這個項目失敗了,而是接口測試沒有推廣下去。
這個緣由就顯得更爲冷酷了:
1. 成本壓力: 接口測試的介入,並無減小功能測試的時間,增長的十幾人天都是額外的成本。對項目質量的提高由於沒有對比數據,因此沒法體現;
2. 週期壓力: 測試須要較完備的接口文檔,才能支撐測試。理論上接口文檔應該在項目設計階段定義,但實際項目並無接口文檔,swagger的信息也是簡單的不能再簡單了。開發人員須要額外的時間編寫文檔,測試人員須要額外的時間測試,客戶又不會給足夠的週期;
總結:
第四次失敗——內部客戶大於外部客戶
有一天老闆找到我,說有一個純測試的項目須要評估一下。拿到信息以後作了基本的梳理,政務類項目,邏輯簡單可是表單超級多,搬磚的活。將信息反饋給老闆並與老闆再次交流以後個人結論是-作不了,團隊當時處於滿負荷工做。後來與老闆交流了幾回,個人反饋都是作不了。最後老闆找了幾個在校的實習生來協助我,因而開始接觸客戶。在於客戶的幾回交流中,客戶的訴求是但願能節約成本,可是我仍是堅持質量第一位,最終客戶接受了咱們的方案。項目最終順利的作了下來,80多人天,900個bug,40000條用例,數據看還不錯。爲何也算成失敗了?
1. 沒有知足內部客戶的訴求: 老闆帶過來的項目,可能有不少的考慮,好比利潤,好比搭上新的客戶等等。我在接收到信息以後,第一反應是個人團隊消化不掉就不要作了,徹底沒有考慮到要替老闆攻下這個山頭。
2. 沒有知足外部客戶的訴求: 在客戶頻繁的表達想下降成本的時候,沒有站在用戶的立場,可能政務類項目的質量標準和其餘客戶並不相同,可能這只是個演示版本,後期還會有更大的變更,種種可能都沒有去過的考慮。雖然客戶承認了咱們的方案,可是結果就是客戶再也沒有和咱們進行測試類的項目合做。
總結:
第五次失敗——裁人風波
這是個敏感話題,對我產生了比較深遠的影響。團隊有一個小姑娘,在公司的一年中總體變現平平,且呈現了較明顯的下滑趨勢。有三個問題讓我開始認真考慮:1 與團隊合做的時候常常發生爭吵。有一次他們兩我的在針對一個測試點交流的時候,另外一位同事問她,這個有沒有測過,小姑娘在辦公室就急眼了,意思是你不信任我就本身幹吧;2 工做時間老是玩手機,消極怠工,負面情緒對團隊產生了比較大的影響;3 bug產量持續墊底,我對比了她參與的所有項目,bug數量都是最少的,且差距很是大。在持續觀察了一段時間以後,綜合考量了產出,貢獻,資質,成長空間和對團隊帶來的影響等方面,最終決定作辭退處理。由綜合部門出面處理了這件事情(協商處理,沒有發生法律風險)。
這件事又爲何定義成失敗,主要兩方面的緣由:
1. 沒有對綜合部門作到足夠的支撐: 在作出辭退決定是,並無第一時間給與綜合部門足夠的數據支撐,最終可拿出的數據維度也相對單一,爲綜合部門面談形成了不小的困難;
2. 沒有及時反饋: 在團隊成員出現問題的時候,沒有在第一時間作出反饋,或者在反饋幾回以後喪失了對成員的信息,致使狀況發展到了一個你們都不太緣由看到的局面;
總結:
1 淘汰機制是公司層面制定的,可是部門內部應該有足夠的績效數據積累,在必要的時候能夠給公司提供客觀公正的數據;
2 及時反饋在團隊管理中是很是重要的原則,當發現成員行爲出現誤差的時候,第一時間給予反饋,及時糾偏才是對他、對團隊負責任的表現。當你想要放棄一我的的時候,其實也是放棄了本身。
第六次失敗——搭對不匹配
前面提到的1+N模式,是咱們團隊長時間使用的搭對模式。期初效果明顯,兩人合做,一人負責在項目中磨合的很順利,測試質量也呈現了上升趨勢。其中一個項目還實現了咱們第一個二輪驗收經過的突破。可是在年底的時候,忽然就發生了一些意外情況。其中一組是A,B兩我的搭檔,A是有一年工做經驗的小姑娘,做爲負責人。B是實習生轉正的小弟弟。A姑娘能力特別強,執行力強,認真負責可是有暴力溝通的問題,B弟弟態度也端正,就是特別軸,認死理。
B弟弟還有一個有意思的事,有一次部門內部分享是B弟弟主講,在過程當中提到了很對知識點,可是這些知識點不是此次分享的重心並且他也沒有準備這些知識點的內容,形成了大部分時間都在討論一些與分享無關的且沒有結論的內容。分享結束後,我找B弟弟交流了一下,說非重點內容能夠帶一下就行了,不須要太展開討論。結果在第二期的分享時,B弟弟整場說了不下20句,這個點大家本身百度吧,我不講了。走了另外一個極端。
說回來,他們兩個合做比較長的時間都還相安無事(後來證實是我本身爲相安無事),直到一次由於一個bug的處理髮生了比較直接的衝突,正好我在辦公室。
衝突結束以後我先和B弟弟交流了一下,B的意思就是對A的經驗很是不屑,以爲本身工做幾年以後也會有經驗,感受讓A負責項目他很是委屈,限制了他的發展。以後我又和A交流了一下,核心就是B作的不對(事實證實確實是B作的不對)還不聽她的,常常是她本身承擔很是大量的工做來彌補B的過失。
在這件事上,我沒有選擇和稀泥,安撫並引導了A的情緒,批評了B的執拗。結果就是B沒過多久就離職了,而A則快速的成長起來。
對於這件事的結果,我以爲不算是失敗,可是致使這一結果的過程倒是完全的失敗:
1. 人員分配考慮不全面: 在搭對的選擇上,我考慮了能力的差別,和後期人員培養的規劃,漏掉了性格的因素,這偏偏也是致使失敗的最重要的因素。95後的孩子都頗有個性,將兩個尖銳的點放在一塊兒,就會產生不可逆的後果;
2. 對團隊觀察不夠細心: 沒有從平時的交流中發覺端倪,當問題明顯化以後,再想彌補就幾乎不可能了。
總結:
1 團隊合做,要綜合考慮,能力、潛力和性格都是決定性因素,爲你們創造一個和諧的工做環境,比什麼都重要;
2 對團隊成員要用心觀察,有些不太正常的跡象時,要及時引導。沒事打打預防針,要比出問題了在解決成本要低的多,況且不是全部問題都能解決。
待續······