<code id="ebytu"><sup id="ebytu"><track id="ebytu"></track></sup></code>
    <td id="ebytu"><option id="ebytu"></option></td>
    <pre id="ebytu"><label id="ebytu"><menu id="ebytu"></menu></label></pre>
    <acronym id="ebytu"><label id="ebytu"><xmp id="ebytu"></xmp></label></acronym>
  1. <td id="ebytu"></td>

    <track id="ebytu"><ruby id="ebytu"></ruby></track>

            作為測試經理的兩年,我都做錯過哪些事?

            發表于:2022-12-15 09:43

            字體: | 上一篇 | 下一篇 | 我要投稿

             作者:luner_z    來源:博客園

            分享:
              我是一名測試經理,在過去的兩年時間做了兩件事,團隊從0到1的搭建和從QC到QA轉型。這兩年沒有什么精彩的故事,都是一次次的嘗試-失敗-嘗試的過程。
              公司背景
              近兩年主要做項目外包?蛻羰茄肫,我們做完的項目要過他們的測試部驗收,測試超過兩輪要罰款。他們通過的標準是一般問題不超過三個,輕微問題不超過五個。
              第一次失敗——冒進的左移
              團隊組建后,我等到了第一個全新的項目A。這個項目對我和我的團隊來說都是至關重要的,我們需要這個項目來給自己樹個標桿,開個好頭。
              于是我把過去兩年我認為最有效的測試方案應用到項目-測試左移。在項目經理的配合下,我們將項目按模塊進行了拆分,并配合著制定了開發計劃和測試計劃,一切都有條不紊的進展著。隨著項目的推進,一個致命的問題暴露了出來——返工。大量的工作被推翻重做,項目周期也延遲了一個多月。在這一個多月中,測試和開發團隊都在不斷的返工中度過。項目最后的交付質量也是慘淡收場——驗收五輪。
              項目結束后,我反思了失敗的原因:
              1.測試方案的激進:在對項目的整體難度和項目團隊能力有充分認知前,貿然的選擇了最激進的左移,致使測試工作節奏混亂,在后期的不斷返工過程中,成員情緒也有很大的影響。
              2.里程碑拆分不科學:在開發計劃制定好之后,匹配測試計劃時,單純的只考慮了完成了哪些就測試哪些。完全沒有考慮到模塊間耦合的問題,沒有考慮后面開發和修改bug對已完成工作的影響,也是造成返工作主要原因。
              3.變更失控:這個項目的需求前前后后修訂了幾十版,一部分是客戶頻繁的提出新的要求,另一部分是因為在項目進行過程中自己發現的的坑,不得不一次一次的填坑。變更失控,勢必造成無休止的返工和延期。
              4.低估了項目難度:項目初期測試針對項目數據方面的邏輯設計了數據模型,但是隨著項目的不斷深入,測試和開發達成的一致被不斷的推翻,甚至在最后交付前,核心的數據邏輯測試和開發還發現有部分分歧。
              錯過了兩次補救的機會
              在第一次出現返工時,沒有認識到根源問題,仍然安排測試人員全程的跟進。錯失了第一次調整方案的機會;
              在變更頻率表現異常是,同樣沒有深入的挖掘問題,還在盲目一條路走到黑。錯失了第二次調整方案的機會;
              總結:
              所有的方案確定都要依賴于對環境的充分了解和分析,每一個項目都是獨特的,盲目的套用會死的很慘;
              每一個問題都不是個例,它背后一定有隱藏的原因,深入的挖掘問題才能避免更多的問題出現。
              第二次失敗——不靈活的“靈活”
              團隊組建之初,項目并行是我們面臨的一個巨大的考驗。于是在項目B上,我嘗試了團隊的靈活切入切出,希望實現人員的可插拔。
              在項目B中,每個階段開發完成我都會嘗試更換一名測試人員,希望鍛煉團隊面對項目時的靈活性。項目B前前后后參與的測試人員有5名,最后的交付質量同樣是五輪驗收。
              又是熟悉是場景,卻有不同的原因:
              1.項目盲區:人員變更勢必造成對項目和需求的盲區,每個人負責自己的階段和模塊,即使多做一些,仍然不足以覆蓋到整個項目的盲區,盲區就Bug的溫床;
              2.人人負責=沒人負責:當所有參與項目人都知道我只會在項目中工作一小段時間,當要求所有參與項目的人對項目負責的時候,就是沒人會對項目負責;
              3.測試工作很失。涸趯蛻趄炇盏膯栴}做整體分析之后,發現75%的問題是因為我們對客戶驗收標準的不對齊導致的,如兼容性要求,需求文檔要求,用戶場景要求等,都被我們忽略掉了。
              總結:
              靈活可插拔,并不意味著所有人都需要頻繁的變動,1+N的模式會更好。即一個負責人,加上N個可調整的測試人員;
              每個項目有且只有一個負責人對項目負責,亙古不變的真理;
              對齊標準永遠是第一要務,要芝麻給西瓜的事千萬不能干。
              第三次失敗——成本才是王道
              公司的項目全部都是功能測試,本著提升團隊素質和產品質量的初衷,開始推進接口測試。在給團隊做了兩期的基礎概念加工具使用的培訓之后,找到項目經理選定了一個周期相對寬松的項目開始了接口測試之旅。過程整體符合預期,兩周的時間完成了用例設計到測試的全部內容。發現了一些項目問題,團隊也積累了實戰經驗。但是還是失敗了,這次失敗不是這個項目失敗了,而是接口測試沒有推廣下去。
              這個原因就顯得更為冷酷了:
              1.成本壓力:接口測試的介入,并沒有減少功能測試的時間,增加的十幾人天都是額外的成本。對項目質量的提升因為沒有對比數據,所以無法體現;
              2.周期壓力:測試需要較完備的接口文檔,才能支撐測試。理論上接口文檔應該在項目設計階段定義,但實際項目并沒有接口文檔,swagger的信息也是簡單的不能再簡單了。開發人員需要額外的時間編寫文檔,測試人員需要額外的時間測試,客戶又不會給足夠的周期;
              總結:
              擴充技能樹是好事,但是目的應該是節省成本。任何不考慮成本的投入都是耍流氓;
              技能的應用應該更靈活,比如在里程碑中加入接口測試做驗收,事半功倍。一味的放在集成測試中必然不會成功。
              第四次失敗——內部客戶大于外部客戶
              有一天老板找到我,說有一個純測試的項目需要評估一下。拿到信息之后做了基本的梳理,政務類項目,邏輯簡單但是表單超級多,搬磚的活。將信息反饋給老板并與老板再次交流之后我的結論是-做不了,團隊當時處于滿負荷工作。后來與老板交流了幾次,我的反饋都是做不了。最后老板找了幾個在校的實習生來協助我,于是開始接觸客戶。在于客戶的幾次交流中,客戶的訴求是希望能節約成本,但是我還是堅持質量第一位,最終客戶接受了我們的方案。項目最終順利的做了下來,80多人天,900個bug,40000條用例,數據看還不錯。為什么也算成失敗了?
              1.沒有滿足內部客戶的訴求:老板帶過來的項目,可能有很多的考慮,比如利潤,比如搭上新的客戶等等。我在接收到信息之后,第一反應是我的團隊消化不掉就不要做了,完全沒有考慮到要替老板攻下這個山頭。
              2.沒有滿足外部客戶的訴求:在客戶頻繁的表達想降低成本的時候,沒有站在用戶的立場,可能政務類項目的質量標準和其他客戶并不相同,可能這只是個演示版本,后期還會有更大的變動,種種可能都沒有去過的考慮。雖然客戶認可了我們的方案,但是結果就是客戶再也沒有和我們進行測試類的項目合作。
              總結:
              對待內部客戶應該像是對待家人,解決他們的問題應該是放在第一位考慮的事。就像孩子過來跟你說我餓了,你的第一反應應該是我要想辦法給你弄點吃的,而不是我沒有錢。
              對待外部客戶應該挖掘核心的訴求,滿足客戶才能帶來長期的勝利。
              第五次失敗——裁員風波
              這是個敏感話題,對我產生了比較深遠的影響。團隊有一個小姑娘,在公司的一年中整體變現平平,且呈現了較明顯的下滑趨勢。有三個問題讓我開始認真考慮:1與團隊合作的時候經常發生爭吵。有一次他們兩個人在針對一個測試點交流的時候,另一位同事問她,這個有沒有測過,小姑娘在辦公室就急眼了,意思是你不信任我就自己干吧;2工作時間總是玩手機,消極怠工,負面情緒對團隊產生了比較大的影響;3bug產量持續墊底,我對比了她參與的全部項目,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對團隊成員要用心觀察,有些不太正常的跡象時,要及時引導。沒事打打預防針,要比出問題了在解決成本要低的多,何況不是所有問題都能解決。
              本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系51Testing小編(021-64471599-8017),我們將立即處理
            價值398元的測試課程免費贈送,填問卷領取吧!

            關注51Testing

            聯系我們

            快捷面板 站點地圖 聯系我們 廣告服務 關于我們 站長統計

            法律顧問:上海漕溪律師事務所 項棋律師
            版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2022
            投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

            滬ICP備05003035號

            滬公網安備 31010102002173號

            亚洲春色校园小说_欧洲精品色在线观看视频_国产思思99RE99在线观看_天天躁日日躁狠狠躁日日躁

            <code id="ebytu"><sup id="ebytu"><track id="ebytu"></track></sup></code>
              <td id="ebytu"><option id="ebytu"></option></td>
              <pre id="ebytu"><label id="ebytu"><menu id="ebytu"></menu></label></pre>
              <acronym id="ebytu"><label id="ebytu"><xmp id="ebytu"></xmp></label></acronym>
            1. <td id="ebytu"></td>

              <track id="ebytu"><ruby id="ebytu"></ruby></track>