如何搞垮一個測試團隊？
要想徹底搞垮一個測試團隊并非易事，需要多角色通力配合、多方聯(lián)動、綜合施策，才能達到目的。
本文從實踐經(jīng)驗出發(fā)，為大家總結(jié)了搞垮測試團隊的18項措施，或許可以給大家?guī)硪恍﹩l(fā)。
—?1?—
QA作為質(zhì)量管理者，在搞垮測試團隊的過程中必然責(zé)無旁貸、沖鋒在前。
1、所有線上事故測試主責(zé)
任何線上事故，一定要第一時間質(zhì)問測試“為什么沒測出來”？最好和產(chǎn)品、研發(fā)、運維一起追問測試，最后在公司大群里發(fā)問（人數(shù)越多效果越好），并@測試團隊的主管（措辭越激烈效果越好）。
不要和我講需求場景未定義，也不要講開發(fā)做了改動沒通知——測試就是質(zhì)量的代言人，必須對質(zhì)量承擔(dān)主要責(zé)任。
2、定義盡可能多的度量指標(biāo)
德魯克說：“你如果無法度量它，就無法管理它?！彼裕琎A要編織極為細密的度量之網(wǎng)，監(jiān)控所有測試細節(jié)：
缺陷打回率，要作為測試團隊的考核指標(biāo)。怎么？你擔(dān)心測試不敢提BUG了？怕什么，有漏測率度量在等著你。
度量用例發(fā)現(xiàn)的BUG占比，如果過高需要反思是否用例不夠多，如果過低需要反思是否用例質(zhì)量差（發(fā)現(xiàn)不了問題的用例一定不是好用例）。
不要度量開發(fā)人均缺陷數(shù)，而要度量測試人均缺陷數(shù)，誰讓測試是負(fù)責(zé)提BUG的呢？
如果你能想到更多的度量指標(biāo)，不用想清楚為什么度量、指標(biāo)說明了什么，只管先拿來度量，在實踐中檢驗它的作用。
—?2?—
3、盡量壓縮測試時間
VUCA時代的項目經(jīng)理可不好當(dāng)，項目計劃經(jīng)常出現(xiàn)延期。開發(fā)提測延期了怎么辦？作為測試人員，必須要做到結(jié)果導(dǎo)向、使命必達！克服困難，加班搞定！
不就是3天的測試時間壓縮到1天嘛，老板本來希望壓縮到半天，還好我多給你們爭取了半天時間。這次情況特殊，下不為例（要讓這四個字成為測試人員最熟悉的聲音）！
—?3?—
產(chǎn)品經(jīng)理在搞垮測試團隊過程中，起到的作用就比較大了。
4、需求質(zhì)量越差越好
產(chǎn)品經(jīng)理是堅定的敏捷實踐者，敏捷宣言都說了：“只要工作的軟件，不要詳盡的文檔”。所以我們要關(guān)注軟件是否正常工作，需求文檔并不重要，這可是大師們說的撒。
需求要盡量做到：
需求描述別太清晰，避免過度定義細節(jié)引起的設(shè)計浪費；
需求顆粒度越大越好，所有相關(guān)特性盡量一次搞定，符合“一次把事情做好”的理念；
不同產(chǎn)品經(jīng)理提的需求要有一些邏輯沖突，以此促進產(chǎn)品、開發(fā)和測試“面對面的溝（吵）通（架）”；
另外，為了提高需求評審（如果有的話）效率，最好不要測試參與，減人增效。
5、需求變動越多越好
敏捷的核心，是以更快的速度、更低的成本擁抱變化。所以需求要盡可能頻繁變更，保證滿足用戶和市場的最新需要。
當(dāng)然，變更的需求中有些是由于產(chǎn)品經(jīng)理調(diào)研不夠、考慮不周導(dǎo)致，不過這些只是少數(shù)（只有少數(shù)不是）。
溫馨提醒：這項措施在搞垮測試團隊時要慎用，因為容易先把開發(fā)團隊搞垮，違背了精準(zhǔn)施策的原則。
6、千萬別做驗收
產(chǎn)品驗收本來就是可有可無、走個過場而已，需求文檔白紙黑字寫得清清楚楚，需要產(chǎn)品經(jīng)理驗收什么！
既然驗收測試也是“測試”，當(dāng)然要測試人員保證。如果產(chǎn)品效果和用戶預(yù)期產(chǎn)生了偏差，那是測試能力不足的表現(xiàn)。
如果個別產(chǎn)品經(jīng)理沒堅守這條原則，產(chǎn)品上線前才去驗收并發(fā)現(xiàn)一些問題，一定要投訴并質(zhì)疑測試的工作能力。
—?4?—
開發(fā)作為測試“相愛相殺”的伙伴，在搞垮測試團隊的過程中，承擔(dān)著至關(guān)重要的作用。
7、分支越多越好
分支管理能力是開發(fā)專業(yè)能力的體現(xiàn)，要努力做到以下幾點：
堅持“分支為王”的原則，能拉分支解決的問題，千萬別考慮其他方案；
缺陷的修復(fù)一定要及時合入各分支，每個分支都要求測試驗證一遍，這才是工匠精神；
分支之間的合并，越頻繁、越復(fù)雜越好，每次合并都要求測試驗證一遍；
測試需要熟悉主分支、功能分支、臨時分支的實時情況，如果自己打錯了包，不要來找開發(fā)。
8、不要談可測試性
今天，一位測試人員找我增加接口、增加日志，他說否則做不了測試。
兄弟，我是開發(fā)，我寫代碼只考慮功能是否用得了，能否測得了是你們測試的事情啊，為啥來找我呢？
術(shù)業(yè)有專攻，開發(fā)寫代碼，測試做驗證。分工多明確，世界多美好。
9、不需要自測
作為多年經(jīng)驗的程序員，我對自己的代碼信心十足。我寫完代碼，只要本地編譯通過，就可以提交了。
我沒做過自測，也沒有出過什么大問題??！反正有測試在后面兜底，有問題測試自然會來找我的。
開發(fā)兄弟們請想想：省下自測的時間，多開發(fā)幾個功能，多解決幾個BUG，難道不是提高產(chǎn)出的好方法嗎？
10、不要做設(shè)計方案評審
一位新來的測試，今天問我“什么時候評審設(shè)計方案”？能問這樣的問題，一看你就是新來的。
首先，設(shè)計方案是給開發(fā)看的，你們測試能看懂？其次，測試要以需求為依據(jù)，如果以技術(shù)方案為依據(jù)，我們方案寫錯了你們是不是也測錯了？再次，評審技術(shù)方案的前提，得是有技術(shù)方案，問題是我們有嗎？
11、不要寫缺陷備注
每次我修復(fù)完一個BUG，直接將BUG單狀態(tài)轉(zhuǎn)為“待驗證”就萬事大吉了。BUG是測試自己提的，難道還不清楚怎么回歸驗證？
有的缺陷管理系統(tǒng)強制要求填寫備注，怎么辦？這種小伎倆哪能難住我這種資深開發(fā)工程師？只需要填寫“已解決”三個字就可以了。什么，擔(dān)心被測試投訴？我們這么多開發(fā)，大家都這樣做，他們能投訴得過來？“法不責(zé)眾”你了解嗎？
—?5?—
外因是變化的條件，內(nèi)因才是變化的依據(jù)。要想迅速有效地搞垮測試團隊，測試自身必須重點發(fā)力、加快進程。
12、測試就是開發(fā)的跟班
測試就是開發(fā)的跟班小弟，是負(fù)責(zé)給開發(fā)“打下手”的。具體案例包括：
開發(fā)讓我測啥我就測啥、讓我怎么測我就怎么測、讓我測哪個版本我就測哪個版本；
性能優(yōu)化同步給開發(fā)做驗證，開發(fā)改一點、測試驗一下，開發(fā)再改一點、測試再驗一下……“結(jié)對編程”效率高；
刷機、抓包、導(dǎo)日志、跑數(shù)據(jù)，測試要像保姆一樣貼心，全方位服務(wù)開發(fā)團隊。
你問為啥刷機這樣的事情不寫個操作說明給開發(fā)？開發(fā)說了：這類事情，測試來做更專業(yè)（內(nèi)心想法：我怎么會做這么low的事）！
13、測試不需要了解實現(xiàn)
測試是代表用戶發(fā)聲的，要完全站在用戶角度驗證需求。更何況我們做的是黑盒測試，什么是黑盒？就是不管技術(shù)實現(xiàn)原理，只看輸入輸出就行！
產(chǎn)品需求是定義“做什么”，開發(fā)實現(xiàn)是定義“怎么做”，測試要驗證的應(yīng)該是“做什么”、有沒有做對。開發(fā)的實現(xiàn)邏輯，很容易把測試的思路帶偏，甚至把測試帶到坑里去。測試同學(xué)一定要看需求，不要看實現(xiàn)。
14、流程規(guī)范并不重要
流程規(guī)范雖然有些作用，但是并不那么重要。有的測試部門制定那么多的流程規(guī)范：缺陷提交規(guī)范、缺陷定級規(guī)范、測試用例設(shè)計/評審/執(zhí)行規(guī)范……請問會有幾個人認(rèn)真看呢？
我也算是“老測試”了，隨手就能列出一堆流程規(guī)范的常見問題：
拍腦袋定義，不符合實際情況；
描述太空泛，不具備可操作性；
不夠全面，實際經(jīng)常遇到未定義的情況；
更新不及時，沒有隨著業(yè)務(wù)變化而修改；
多個流程規(guī)范“打架”，自相矛盾，讓人無所適從
細節(jié)太多，看了根本記不住……
流程規(guī)范有這么多問題，足以證明弊大于利。
15、自動化測試是核心能力
不要相信“測試設(shè)計能力才是測試的核心能力”這種話。你看看身邊技術(shù)水平高、職位高、薪資高的，不都是自動化測試達人嗎？只有代碼能力強，你才能站在測試金字塔的塔尖上去。
開發(fā)工程師轉(zhuǎn)崗做測試，人家立即就是資深的測試工程師，畢竟人家自動化能力杠杠的。
16、不需要讀書學(xué)習(xí)
專家說過：“工程師的經(jīng)驗70%來自工作實踐，20%來自同事經(jīng)驗傳遞。”這兩項加起來就是90%！我們來算算這筆賬，為了那10%的經(jīng)驗，點燈熬夜地去讀書學(xué)習(xí)，是不是得不償失？
更何況，大多數(shù)人都是讀書時激動、讀書后感動、讀完后不動。讀完了也記不住，用的時候還不如搜索引擎來得快（別看廣告看功效）。有讀書那工夫，刷刷短視頻放松一下，勞逸結(jié)合，它不香嗎？
—?6?—
17、加班越多越好
這團隊啊，必須要忙起來才行。人一閑下來，就會胡思亂想，搞小動作。剛聽說兄弟團隊最近兩個月比較閑，結(jié)果離職了好多人，有一位報了算法學(xué)習(xí)班在工作期間刷題練手的，還有一位考了教師資格證準(zhǔn)備轉(zhuǎn)行的。
咱們團隊要吸取教訓(xùn)，雖然我們沒有加班文化，但務(wù)必要保證每個人的工作飽和度，每天時間排期要精確到小時。加班強度要作為考核和評優(yōu)的參考依據(jù)，任務(wù)排期要把晚上和周六也排上。不多給團隊一點壓力，怎么能激發(fā)大家的潛力？
—?7?—
18、去測試化
測試并不直接生產(chǎn)企業(yè)的產(chǎn)品，因此常被看做成本中心。你看幾年前微軟CEO的去測試化不是很成功嗎？裁減大量測試人員同時保證了質(zhì)量，不信的話可以某度搜索“win10 bug”看看。
實際上很多時候，用戶根本不需要那么高的質(zhì)量，公司花錢養(yǎng)這么多測試人員是不是浪費？去測試化還是要搞起來的。只不過，“去測試”不等于“沒測試”，測試活動仍然存在，只不過從測試扔給開發(fā)了。各位開發(fā)兄弟們，測試的鍋已經(jīng)被砸，你們好自為之，做好自己背鍋的準(zhǔn)備吧。