為什麼產品驗收時還有一堆bug？

為什麼明明寫了 1000 多條測試用例，迴歸測試測了幾個小時，等產品經理驗收時，還是一堆 bug？

產品經理最終對產品的交付效果負責，客户有問題時，他不能説：這不是我的問題，我產品設計是沒問題的，是測試人員沒測出來；所以我們除了產品規劃外，還花了很多的精力在測試驗收上。

之前我們產品經理參與驗收的環節有很多：靜態頁面驗收、開發環境驗收、測試環境驗收、上線後產品驗收。

對於產品經理來説，一個給力的測試至少能減少 50% 的工作量；我們都希望只最後驗收一遍，而且是一遍過。

當我們的願望達不成時，我們就得回過頭去看看測試的問題，看是否可以改善。

一、迴歸測試測全了嗎？

這一點其實是我們不願意去質疑的，這是測試人員的責任問題。

但我們在驗收時常常忍不住想：測試真的有測過嗎？

比如説這個頁面的字段少了，這種最基本的問題，測試都看不出來嗎？

比如這期上線內容和某些模塊沒有關係，頁面查看和點擊頁面上按鈕時也都是正常的，但當你去保存或者修改時報錯了，這難道不屬於迴歸測試範圍內的？

可能測試把注意力放在了新增功能上，主觀覺得某些功能不會有問題，就沒有執行完整的測試用例。

不過這一點還是要承認的，測試時間一般都是比較緊的，有時候人手還不夠，測試壓力很大，有所側重的測試；理論是沒問題的，有時就看運氣好不好了，出現問題的概率和嚴重程度有多大。

二、只關心流程，不關心體驗

有時候我也會去參加測試人員的面試，我比較關心的一個問題是：你們測試時會看樣式嗎？體驗感覺不好時會提嗎？

可能是這些年有些心理陰影了吧——遇到過一些測試，覺得樣式和體驗是和他們無關的事情；從公司責任劃分來看，這也沒什麼問題，誰都不想給自己攔很多活，況且一些是偏主觀，不能定量的。

從產品經理角度來説，希望團隊中人人都是產品經理，大家可以齊心協力，奔着把產品做好的同一個目標去。

可能是我們的期望太高，也沒有向測試傳達清楚；那後面責任劃分時可以要求他們樣式對照 UI 稿測，記錄前端 bug，體驗問題只能説盡量提出，給我們一些建議。

三、沒從現實場景出發

這個問題我們也經常會遇到，哪怕我們按照我們的要求驗收通過了產品，領導或者客户點的時候，還是一堆 bug。

因為每個人在使用產品時，場景不一樣，使用方法也不一樣，就會出現很多預料之外的問題。

主要還是下面2點原因：

1. 數據過於測試化

大部分的測試數據都是“111,222”，測試“產品1”這種，按照測試用例來測試時是沒問題；但一旦把數據換成用户的真實數據，問題就很多了。

最常見的是字符長度問題，一般字段長度限制是 32,64,128 這種，測試數據長度太短時顯示沒有問題，一旦長一點，頁面可能都亂了；比如藥品名稱，測試數據是“芬必得”，真實名稱是“芬必得布洛芬緩釋膠囊”。

我們經常讓測試做邊緣測試，但事實上不可能所有字段都做，那怎麼區分哪些要做，哪些不要做呢？最好的方法就是拿一家典型客户的數據來做測試，儘量避免寫 111 這種。

2. 沒模擬用户使用路徑

簡單來説，沒有站在用户的角度去測試產品；這個點或許對測試來説要求是有點高，絕大部分人能按測試思維，把產品測完就已經不錯了。

這和上面一個點也是有非常大的關係的，我在測試環境測的時候，也常常發現不了問題，為什麼？因為看着一些過於測試化的數據時，我都想不出下一步該去操作什麼；所以一般產品經理都會建一些相對比較真實的自己的數據，而不是用測試數據。

最關鍵的還是這個點：互聯網人對產品業務的理解太淺，甚至是不理解，特別是 B 端產品；大部分的開發和測試，沒有接觸過客户，沒有去過實地，單靠產品經理的講述，很難建立三維的感觀。

像醫療、工業這種都是門檻比較高的，可能醫院我們還去過，對於醫生的看診流程還體會得到；但工業就離我們比較遙遠了，真的是從來沒有去過工廠，很難理解為什麼有些產品不看編號、看圖號，入庫產品包裝上為什麼沒有條碼，為什麼鋼材還要關心爐批號。

如果公司允許，能帶着開發和測試去實地看看，對產品開發是有很大幫助的。

四、總結

產品有 bug，先不要想這個鍋應該誰來背。

• 產品經理會説：測試沒有測到位；
• 測試會説：開發水平太差，bug 太多；
• 開發會説：你的產品文檔沒寫清。

還是要強調這個事：產品不是一個人的事，是大家的事；我們把甩鍋的時間用在分析問題、制定解決方案上，會更加有效。

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產品經理專欄作家。8年+互聯網資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業互聯網產品相關的硬核知識點。

本文原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議。