導讀
????我們測試人員承擔著“保障質(zhì)量”的使命，這個使命有時候會導致這樣一個現(xiàn)象：
當我們測試的某款產(chǎn)品上線后梳庆，暴露出一些影響嚴重的bug宋雏。這時候項目團隊中第一時間想到的問題是张峰，當初測試人員是怎么測試的牛柒？堪簿！竟然這樣的缺陷都沒有發(fā)現(xiàn)！他們會從潛意識里忽視皮壁，質(zhì)量保障是全員全流程的事兒戴甩，出了事故，并不能僅從我們測試身上找問題闪彼。
快到約定的上線時間了，但系統(tǒng)測試還沒有結(jié)束协饲。此時領(lǐng)導問項目經(jīng)理畏腕，為什么到現(xiàn)在還不能上線，項目經(jīng)理回答說我們在一個月之前就送測了茉稠，測試人員已經(jīng)開工很長時間了描馅，具體情況需要讓測試人員來說一下為什么測試了那么久還沒結(jié)束。
? ? “背鍋”的事兒筆者經(jīng)歷了很多而线，分享一下我的感受铭污。由于文筆所限，可能會導致部分內(nèi)容有“引戰(zhàn)”的嫌疑膀篮，如果有請告知嘹狞，筆者希望本文的分享是給您帶來一些新思路，而不是引起您的不適誓竿。
????談到這個話題磅网，也許很多人下意識會想到如何“甩鍋”，想著如何把責任撇清筷屡。這個方法雖然必不可少涧偷，但建議少用簸喂。因為一旦出現(xiàn)了質(zhì)量事故，無論解釋的多么天花亂墜燎潮，都于事無補喻鳄，反而容易讓人覺得你這個人不可信、不可交确封。說的越多除呵，越讓領(lǐng)導反感，覺得我們在找借口隅肥！
換句話說竿奏，如果真這么干了，那方向可能就錯了腥放。我個人覺得可以從下面這幾方面來考慮泛啸。
一、測試前進行充分溝通秃症，測試范圍和風險
跟開發(fā)詳細確認需求候址，確認的時候注意方法，比如對方講完了之后重復對方的意思來確認种柑，回頭還可以用郵件的方式讓對方再次確認岗仑。
有郵件的方式把測試范圍發(fā)送項目干系人。一方面讓收件人確認自己的理解是否正確聚请，一方面收件人也會在發(fā)現(xiàn)信息錯誤時進行修正荠雕。
把風險告知測試經(jīng)理（或者項目經(jīng)理），包括質(zhì)量風險和進度風險驶赏。
在閱讀需求文檔方面炸卑，筆者也分享過一些能提高效率和閱讀效果的技巧，可以參考一下煤傍。
二盖文、版本發(fā)布后進行冒煙測試
????冒煙測試的目的是確認版本是否具有可測性，避免測試做無用功蚯姆，這點很重要五续。
三、測試執(zhí)行中的注意點
????把發(fā)現(xiàn)的問題全部記錄在案龄恋，特別是“偶發(fā)”問題疙驾。這樣可以當偶發(fā)問題在線上出現(xiàn)時，我們能理直氣壯的說郭毕，這個問題當初發(fā)現(xiàn)過荆萤。順便說一下，有的測試人員會覺得發(fā)現(xiàn)了問題告訴研發(fā)就可以了，理所當然的認為他們會修改的——我不能完全否定這種做法链韭，比如在項目需要緊急上線時可以這么做偏竟，避免走流程的時間浪費。但我們這一行敞峭，任務重加班多是一種常態(tài)踊谋，這很可能導致開發(fā)人員忘了你跟他說過這個bug，也可能會導致bug沒有徹底修復旋讹，而且萬一以后這個bug又復現(xiàn)了呢殖蚕？屆時我們想查看當初的原因和修改方式都做不到。
四沉迹、測試報告中附加必要的說明
比如我們要帶風險上線睦疫，我們可以在《測試報告》中列出未修復的bug，帶風險上線的原因鞭呕，以及這些對這些bug的規(guī)劃（什么時候修復）蛤育。
五、怎么規(guī)避在“工作效率”方面的黑鍋
提高自己做計劃的能力葫松，具體如何提高可以參考筆者其他文章瓦糕。
記錄并匯報因為送測版本的問題導致的測試延期。
之前好用的功能在新的送測版本中出現(xiàn)了問題腋么，我們可以考慮是否需要立即匯報并將版本駁回咕娄，讓開發(fā)重新打包。
測試執(zhí)行過程中遇到影響進度的問題立即上報
一旦出現(xiàn)致命或者嚴重bug珊擂，并且會（或可能會）導致測試無法進行的問題圣勒，應立即上報，避免信息不對稱摧扇。
如果遇到問題不上報灾而，可能會導致雖然你最后出色的完成了測試任務，在領(lǐng)導心中扳剿，你的工作也是沒有做到位的。
