某天，美国某著名车企客服热线接到一个投诉电话，称他去买冰激凌的时候车会出故障。如果买的是奶油冰激凌，车就没有问题，如果买的是香草冰激淋，则会出现点火故障。
产品质量就是生命。
如何保证产品质量？验证。
如何保证验证的质量？产品所有可能的使用场景都被充分验证。
你的产品防水？放到水里试一下。你的产品高温支持120度？放到温箱加热到120度试一下。你的产品支持高湿？放到高湿环境试一下。那用户去热带雨林能正常使用不？放到高温高湿滴水的环境也试一下。
就像客户开车去买个冰淇淋，他想买什么口味是他的自由，但车不能出问题。
接线员一边认真地听着客户关于汽车故障的投诉，一边满脑子无聊小丑在电话线另一端的表演。
产品测试验证是产品开发很重要的环节。其实是最耗时的环节。
专业的验证从定义测试例开始。从产品主要功能开始，结合可能的使用场景，定义出完备的系统级测试用例。
然后将系统级测试用例分解到产品每个子模块，来定义每个子模块的测试用例。
可是车上什么子模块会这么厌恶香草冰淇淋而罢工以示抗议？或者车上什么模块因为没有吃到奶油冰淇淋而伤心欲绝？
过了几天，这个客户又打电话来投诉同样的问题。
一个产品，尤其是大规模生产的产品投放市场后，会工作在千差万别的环境中，被不同使用习惯的用户操作。这时难免会发生很多产品没有测试到的问题。
过了几天，这个客户又打电话进来。和前几次电话的区别是这个客户明显更愤怒了。这个时候车企决定派员去看看这个客户的车究竟是不是真的有问题。
一个测试员跟着客户上了车，一起去买冰淇淋。去买不同的冰淇淋。
结果证明客户是对的。
这是一个真实的案例。首次听到这个案例时我刚开始管理产品系统测试。
我的第一反应是这怎么可能！这是一辆车！一辆车怎么可能知道买的是什么口味的冰淇淋？怎么可能知道客户停车是去购物而不是去抽烟？
这是产品外场测试出问题后研发团队最抓狂的时候。这也是解决问题的第一步，即准确知道问题是哪里引起的。
一旦知道了问题是哪里引起的，这个问题就已经解决了一大半，而变成一个局部的问题。
随着深入分析测试，这个局部问题会变成更小局部的问题。
如此下去直到问题的根源被发现。
测试人员又一次次观察客户购买不同冰淇淋的过程，试图发现一些蛛丝马迹。
后来他们发现，奶油冰淇淋是大众冰淇淋，冰淇淋店总把它放在最容易取到的位置。香草冰淇淋则被随便放到最角落的某个位置。取香草冰淇淋会花比较长的时间。
这就是这个案例的决定性发现。
这个发现回答了为什么买某种冰淇淋会引发车辆故障而另外一种则不会。决定因素不是口味，而是购物时间的长短，是车熄火到再次点火的时间长短。
后面的故事我就不讲了。感兴趣的朋友可以去找来看看。你会发现我讲的冰淇淋是种类可能完全是错的。 但是没有关系。这不重要。
初次听到这个案例的时候我震惊了。好多年过去了，我不得不心情复杂地说，这个案例其实真的就是一个小case。
与所有产品经理们共勉。
P.s. 20171112重新改了一遍。
