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