最近發(fā)生了一起生產(chǎn)事故，究其根源，事故本身屬于架構(gòu)或者需求層面需要規(guī)避的問題，測(cè)試人員的責(zé)任其實(shí)是非常小的，但實(shí)際情況是：相關(guān)測(cè)試人員因此承擔(dān)了很大的壓力，成為質(zhì)量問題的“背鍋俠”。

實(shí)際上，測(cè)試人員一直處于“背鍋俠”的處境，今天就來聊聊，測(cè)試人員究竟背了哪些鍋？

測(cè)試背的第一層鍋：產(chǎn)品不能如期交付的鍋

我們知道，產(chǎn)品交付排期一般是固定的，很多時(shí)候，我們?cè)谶@個(gè)基礎(chǔ)上，進(jìn)行開發(fā)測(cè)試排期的倒排，而測(cè)試作為產(chǎn)品交付的最后一個(gè)環(huán)節(jié)，經(jīng)常被嚴(yán)重壓縮排期，場(chǎng)景比如：

研發(fā)未能按時(shí)提交測(cè)試版本；

研發(fā)如期交付，但功能并未開發(fā)完，或者交付質(zhì)量很差。

上述兩種場(chǎng)景非常常見，尤其是第二種場(chǎng)景，這時(shí)候測(cè)試人員幾乎是有口難言，人家按時(shí)提交了，交付質(zhì)量差也怨不得人家，但因此帶來很多測(cè)試成本，原來評(píng)估的排期根本不夠用。

更有甚者，雖然交付測(cè)試，但部分功能未開發(fā)完，然美其名曰“敏捷測(cè)試”，這里不是說敏捷測(cè)試不好，只不過實(shí)際過程中，敏捷測(cè)試被濫用了，因此帶來很多測(cè)試人力的浪費(fèi)和排期擠壓。

這兩種場(chǎng)景，帶來的直接后果，就是測(cè)試排期被嚴(yán)重壓縮，如果產(chǎn)品未能如期交付，第一個(gè)被拿出來的理由一定是：未完成測(cè)試。

而為了不背這個(gè)鍋，測(cè)試人員只能壓榨自己，逼自己如期完成。這是測(cè)試背的第一層鍋：產(chǎn)品不能如期交付的鍋，而為了如期交付，測(cè)試人員只能壓榨自己，加班加點(diǎn)。

測(cè)試背的第二層鍋：質(zhì)量不符合預(yù)期的鍋

在產(chǎn)品使用過程中，如果出現(xiàn)問題，第一個(gè)被問責(zé)的對(duì)象就是測(cè)試：測(cè)試人員為什么沒有發(fā)現(xiàn)該問題？

而因?yàn)閹缀醮蟛糠謫栴}都能定性為測(cè)試案例未覆蓋，所以測(cè)試經(jīng)常需要背“質(zhì)量不符合預(yù)期的鍋”。

之所以背這頂鍋，根本原因是業(yè)內(nèi)人員對(duì)測(cè)試人員的職責(zé)定位有誤。

大部分人認(rèn)為測(cè)試的職責(zé)就是為質(zhì)量負(fù)責(zé)，且是負(fù)全部責(zé)任，只要是質(zhì)量問題，測(cè)試就需要承擔(dān)起來。

但，請(qǐng)問質(zhì)量是測(cè)試出來的嗎？顯然不是，質(zhì)量是設(shè)計(jì)出來的。

一個(gè)壞透了的架構(gòu)設(shè)計(jì)，注定產(chǎn)品質(zhì)量會(huì)漏洞百出，測(cè)試無法窮盡所有場(chǎng)景發(fā)現(xiàn)所有問題。一個(gè)好的架構(gòu)設(shè)計(jì)，在設(shè)計(jì)層面就規(guī)避掉了幾乎所有潛在風(fēng)險(xiǎn)。

當(dāng)一個(gè)產(chǎn)品漏洞百出時(shí)，一定是架構(gòu)設(shè)計(jì)的不夠合理，這時(shí)候無論怎么測(cè)試，質(zhì)量都不會(huì)太好，因此，當(dāng)問題出現(xiàn)時(shí)，不應(yīng)該去問責(zé)測(cè)試為什么沒有發(fā)現(xiàn)，而是去反思架構(gòu)設(shè)計(jì)。

總結(jié)來說，很多時(shí)候，測(cè)試成了架構(gòu)設(shè)計(jì)不合理的背鍋俠。

當(dāng)然，這個(gè)結(jié)論的前提是，這個(gè)問題的確是架構(gòu)的問題。如果出問題的是核心流程，測(cè)試的確需要承擔(dān)一定責(zé)任，畢竟基本功能需要確保無問題。

測(cè)試的職責(zé)是驗(yàn)收產(chǎn)品主要功能滿足要求。

測(cè)試背的第三層鍋：緊急出版本的鍋

很多時(shí)候需要緊急出版本修復(fù)問題，這時(shí)候，測(cè)試排期幾乎被嚴(yán)重壓縮。然后，測(cè)試還要擔(dān)著交付后質(zhì)量無問題的責(zé)任，這兩者其實(shí)是互相矛盾的存在：為了保障質(zhì)量，需要充分的時(shí)間去測(cè)試，而排期被嚴(yán)重壓縮，幾乎沒時(shí)間充分測(cè)試，測(cè)試人員深陷其中，苦苦掙扎。

總結(jié)來看：

一方面產(chǎn)品交付前，測(cè)試排期被嚴(yán)重?cái)D壓，測(cè)試需要加班加點(diǎn)去完成測(cè)試，而由于排期被壓縮，測(cè)試可能無法充分展開，存在質(zhì)量隱患。

另一方面，產(chǎn)品交付后，如果真的出現(xiàn)質(zhì)量問題，測(cè)試又會(huì)成為第一個(gè)被問責(zé)的對(duì)象，而為了緊急修復(fù)問題，測(cè)試又需要加班加點(diǎn)去完成測(cè)試，而這時(shí)候測(cè)試周期往往被嚴(yán)重壓縮，無法充分測(cè)試，進(jìn)而又埋下了質(zhì)量隱患。

這不是“背鍋俠”是什么？

如果團(tuán)隊(duì)研發(fā)能力很弱，且對(duì)交付質(zhì)量要求很高或者事故容忍能力很低的時(shí)候，測(cè)試面對(duì)的壓力會(huì)被急速擴(kuò)大，成為“超級(jí)背鍋俠”。

為什么呢？因?yàn)檠邪l(fā)能力弱，代表潛在質(zhì)量問題會(huì)很多，測(cè)試復(fù)測(cè)成本非常大，且交付的產(chǎn)品從根上就注定了功能不穩(wěn)定，導(dǎo)致事故頻發(fā)。如果這時(shí)候產(chǎn)品對(duì)事故的容忍能力很低，那么后果就是測(cè)試需要頻繁的被問責(zé)，以及被要求完成緊急版本的測(cè)試。這種情況下，壓力被嚴(yán)重放大。

如果產(chǎn)品對(duì)質(zhì)量問題的容忍度較高，那么測(cè)試人員暫且還可以承受住這個(gè)“冤屈”，而如果團(tuán)隊(duì)研發(fā)能力很弱，且對(duì)交付質(zhì)量要求很高或者事故容忍能力很低的時(shí)候，就需要考慮“伸冤”了。

如何伸冤

列舉幾條：

擺正測(cè)試人員的職責(zé)范圍，質(zhì)量是設(shè)計(jì)出來的，不好的設(shè)計(jì)一定會(huì)存在很多質(zhì)量隱患，不要上來就問責(zé)測(cè)試。

基于當(dāng)前的研發(fā)能力，對(duì)未來事故的發(fā)生頻率給予合理的預(yù)期，尤其在上面描述的場(chǎng)景下，這時(shí)候，如果還要做大型架構(gòu)設(shè)計(jì)改造，那么未來一定會(huì)出現(xiàn)各種質(zhì)量問題，需要對(duì)質(zhì)量問題有足夠的容忍度，提供寬松的空間讓大家去踩坑，只有這樣才是最為人性的處理。

放緩產(chǎn)品交付節(jié)奏，縮小產(chǎn)品影響范圍，逐步交付，降低事故發(fā)生頻率。

最后：在我的V ：atstudy-js，可以免費(fèi)領(lǐng)取一份10G軟件測(cè)試工程師面試寶典文檔資料。以及相對(duì)應(yīng)的視頻學(xué)習(xí)教程免費(fèi)分享！其中包括了有基礎(chǔ)知識(shí)、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測(cè)試工具、測(cè)試進(jìn)階-Python編程、Web自動(dòng)化測(cè)試、APP自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試、測(cè)試高級(jí)持續(xù)集成、測(cè)試架構(gòu)開發(fā)測(cè)試框架、性能測(cè)試、安全測(cè)試等。