某天，美國某著名車企客服熱線接到一個投訴電話，稱他去買冰激凌的時候車會出故障。如果買的是奶油冰激凌，車就沒有問題，如果買的是香草冰激淋，則會出現點火故障。
產品質量就是生命。
如何保證產品質量？驗證。
如何保證驗證的質量？產品所有可能的使用場景都被充分驗證。
你的產品防水？放到水里試一下。你的產品高溫支持120度？放到溫箱加熱到120度試一下。你的產品支持高濕？放到高濕環境試一下。那用戶去熱帶雨林能正常使用不？放到高溫高濕滴水的環境也試一下。
就像客戶開車去買個冰淇淋，他想買什么口味是他的自由，但車不能出問題。
接線員一邊認真地聽著客戶關于汽車故障的投訴，一邊滿腦子無聊小丑在電話線另一端的表演。
產品測試驗證是產品開發很重要的環節。其實是最耗時的環節。
專業的驗證從定義測試例開始。從產品主要功能開始，結合可能的使用場景，定義出完備的系統級測試用例。
然后將系統級測試用例分解到產品每個子模塊，來定義每個子模塊的測試用例。
可是車上什么子模塊會這么厭惡香草冰淇淋而罷工以示抗議？或者車上什么模塊因為沒有吃到奶油冰淇淋而傷心欲絕？
過了幾天，這個客戶又打電話來投訴同樣的問題。
一個產品，尤其是大規模生產的產品投放市場后，會工作在千差萬別的環境中，被不同使用習慣的用戶操作。這時難免會發生很多產品沒有測試到的問題。
過了幾天，這個客戶又打電話進來。和前幾次電話的區別是這個客戶明顯更憤怒了。這個時候車企決定派員去看看這個客戶的車究竟是不是真的有問題。
一個測試員跟著客戶上了車，一起去買冰淇淋。去買不同的冰淇淋。
結果證明客戶是對的。
這是一個真實的案例。首次聽到這個案例時我剛開始管理產品系統測試。
我的第一反應是這怎么可能！這是一輛車！一輛車怎么可能知道買的是什么口味的冰淇淋？怎么可能知道客戶停車是去購物而不是去抽煙？
這是產品外場測試出問題后研發團隊最抓狂的時候。這也是解決問題的第一步，即準確知道問題是哪里引起的。
一旦知道了問題是哪里引起的，這個問題就已經解決了一大半，而變成一個局部的問題。
隨著深入分析測試，這個局部問題會變成更小局部的問題。
如此下去直到問題的根源被發現。
測試人員又一次次觀察客戶購買不同冰淇淋的過程，試圖發現一些蛛絲馬跡。
后來他們發現，奶油冰淇淋是大眾冰淇淋，冰淇淋店總把它放在最容易取到的位置。香草冰淇淋則被隨便放到最角落的某個位置。取香草冰淇淋會花比較長的時間。
這就是這個案例的決定性發現。
這個發現回答了為什么買某種冰淇淋會引發車輛故障而另外一種則不會。決定因素不是口味，而是購物時間的長短，是車熄火到再次點火的時間長短。
后面的故事我就不講了。感興趣的朋友可以去找來看看。你會發現我講的冰淇淋是種類可能完全是錯的。 但是沒有關系。這不重要。
初次聽到這個案例的時候我震驚了。好多年過去了，我不得不心情復雜地說，這個案例其實真的就是一個小case。
與所有產品經理們共勉。
P.s. 20171112重新改了一遍。
