缺位的服务测试
微博, 朋友圈, 各种论坛, 经常有对不同商家的吐槽, 投诉; 仔细看一下, 发现共同的模式都是 先碰到一个问题, 然后打客服电话请求解决, 没解决, 长时间没解决, 最后只好公开指责. 长时间无法为用户解决问题, 意味着商家的服务, 商家的业务流程出了 Bug.
难道不测试吗? 我们有产品测试, 但很少有人谈论服务测试.
先举一个例子澄清下这里说的”产品”和”服务”分别指代什么. 12306. 12306刚出来的时候, 其用户体验之差掀起了网络上为12306重新设计架构的热潮. 那么12306的体验到底是好是坏?
- 作为一个产品(网站/应用), 12306的用户体验是差的, 最初上线后并发量太大导致服务不可用, 界面半天没反应.
- 作为一个服务, 12306的用户体验是好的, 不用冒着寒风大半夜在马路上排队了, 可以在家里热乎乎的以各种姿势来买票.
这就是这里说的”产品”跟”服务”的区别: 产品通常是某个软件, 或系统, 而服务指的是购票服务, 上网服务, 出行服务的服务(不是端茶倒水, 迎来送往, 微笑服务的服务, 也不是客服呼叫中心等提供的服务, 这个太狭义), 也就是端到端的业务流程.
拿电信服务来说, 常见的一个投诉是未上网产生费用, 莫名其妙的被扣走高额流量费. 如果运营商在接到投诉后不能尽快查明事实, 甚至在事实清楚的情况下不能为用户追回损失, 都是服务的 Bug.
产品发布前, 都会对产品进行测试, 单元测试, 集成测试, 性能测试压力测试等; 那么推出新服务前, 我们是否做服务测试? 面向社会推出服务而不做服务测试, 依赖真实的用户投诉来发现问题, 就类似微软直接发布新版 Windows 或者 Office 依赖用户找 Bug 一样, 后者不可想象, 但前者似乎是现状. 如果你说你做了服务测试, 那么测试用例在哪? 谁执行的? 多少时间执行一次? 结果如何? 发现了多少服务 Bug, 修复了多少?
像测试产品一样测试服务
对于产品测试, 我们已经有完善的理论. 稍微对照一下, 就可以给服务测试提供丰富的指导. 比如产品都要做压力测试, 很多景区的服务显然没有做, 一到节假日高峰就瘫痪.
测试用例的准备
对于产品, 用户每反馈一个 Bug, 都可以补充一个测试用例. 对于已经发布出去的服务, 可以采取类似的做法补充服务测试用例:
- 每一个客服无法顺利处理的案例, 都是我们服务的一个 bug. 每一个需要客服介入的案例, 都是一个服务测试用例;
比如对快递来说, 刻意投诉下物品损坏, 就是一个测试用例.
测试用例的执行
我们需要作为用户, 真实的去体验每一个用例规定的服务流程. 你会说我们也有体验啊...你是按照剧本去体验的吗? 你给客服打电话了吗? 你会重复体验吗? 多久体验一次?
当我们灰度测试时, 我们在灰度些啥?
灰度或者小流量测试, 是被低估的一种测试手段. 除了用于测试产品, 更应该用于测试服务. 小范围的推出一个服务, 比如滴滴的小巴, 就只在回龙观地区进行灰度测试, 测试每一个环节. 当然要像前面说的, 不要总是依赖真实用户去反馈, 要有专门的测试人员作为用户, 刻意的在某个环节掉链子, 比如司机迟到, 比如乘客不支付, 测试平台提供的服务是否能正确处理.
当我们众测时, 我们在众测些啥?
互联网公司的员工往往是自己产品的真正用户, 因此互联网公司都有内部众测的传统. 如果只是关注产品, 则发挥不出内部众测真正的威力. 内部众测应该关注完整的服务体验更多.
服务测试之上, 还有业务测试
服务之下有产品, 其实服务之上也有一个更大的概念, 就是业务(Business). 你的业务能不能正常运转, 获利, 也需要测试, 否则很可能你就成了那个花18万买设备造假币, 只造出16万枚1元硬币的例子. 对业务进行测试的方法论, 已经存在很多了, 最近流行的是精益创业. 是的, 精益创业其实是一种业务测试方法论, 测试你的业务是否成立.
开连锁店的单店盈利模型, 就是对业务模式的测试.
服务测试即服务行业的军事演习
综上, 对比产品测试和业务测试, 我认为目前服务行业中缺乏对服务测试的研究, 理论和实践都相对空白. 产品设计之外, 我们有服务设计, 有商业模式设计, 但对应的测试理论和实践的成熟度, 服务测试显然相对落后.
一个可以借鉴的例子是军事演习. 如果把军队看做战争的服务提供方, 那么武器的测试, 就类似产品测试, 显然战争前仅有武器测试是不够的, 要全方位演练. 服务行业应该像军演那样, 把测试系统化, 常规化.
有什么问题吗?