像用户一样测试:不妨犯傻
The following article is from 圆小豆的美梦工场 Author 于晓南
小时候的第一台电脑:17寸液晶显示器,奔四处理器,全新界面的Windows XP操作系统,标志性的大草垫子桌面。为了和学校的电脑保持风格一致,我还调成了经典主题,类似下图:(这真是一个暴露年龄的悲伤故事)
坐在自己的电脑面前,激动的心情溢于言表,快刀阔斧的把凡是不能直接双击打开的文件全都放入回收站,并清空了回收站。删完以后,看着干净的桌面和文件列表,人机合一的掌控感让我激动不已,像完成仪式一样的关闭窗口、关机、关显示器、关电源,期待着下一次的相遇。
第二天,打开电脑进不去操作系统,重启多次无效。一边着急一边少年老成的胡思乱想:人真是可笑,没有的时候想有,有了又要被东西奴役……
到校以后,邀请班里游戏打的最好的男生来修电脑,对方轻描淡写:“小caes,重装一下就行。” 放学后,他拿着光盘和U盘来帮我装系统:
“这新买的电脑就开不开机了,你可真能造。”“我啥也没干啊!”“啥也没干就开不开了,你肯定干啥了。”“我就整理了一下文件,就这样了。”“你怎么整理的?”“我把没用的文件删了,就是打不开的那种。”“……哪种啊?”“就是带小齿轮的那种,还有花花绿绿的,还有一个大框的,我都删了。”“……你可真有耐心。”“那是,我删了半天呢。”“……这都是系统要用的,你都删了当然开不开机了。”“没告诉我不能删啊,我哪知道,它就不应该让我删!”
时隔多年,那台电脑已经换代N次了,当时的委屈心情还记忆犹新。真实的用户使用场景下,凡是没明确提示不能做的,用户都会去尝试;甚至明确提示不能做的,用户也想着能不能绕过去尝试一下。人都有好奇心,使用软件的乐趣就在于不断探索。打开文件的瞬间,谁知道等待我的是百万大奖还是熊猫烧香?
后来做测试,有了正反两方面的思考:一方面,不被允许的操作,最好连入口都不提供,从根儿上断了用户犯傻的通道,最次也要给用户来个“后果自负”的严重警告;另一方面,删除或限制正在使用的资源,是引起软件失效的常见原因之一。本文尝试从体验的角度来聊聊测试,内容较初阶,旨在引发思考。(毕竟我也不是体验设计师,专业受限请见谅)
”防呆,又称错误校对,是一种预防矫正的行为约束手段,运用防止错误发生的限制方法,让操作者不需要花费注意力、也不需要经验与专业知识,凭借直觉即可准确无误地完成的操作。——维基百科
防呆源自围棋术语,应用于丰田汽车的工业管理,随后被推广到各个领域。防呆设计遵循以下十个原则,让我们从软件的角度来逐一解释。
断根:从根源上避免犯错,不允许的操作置灰或隐藏
牛奶不允许“卖了换钱”,所以就没有这个按钮:
保险:共同或依序运行两个以上的动作完成工作
微信删除聊天记录,左划显示操作菜单,点击“删除”,还需要用户再次确认删除:
自动:将人工操作自动化,减少人为失误;智能地预估、兼容或阻止错误
页面的自动填充、自动提交、自动关联信息等;
午夜后语音上闹铃,“明早7点30叫醒我”,会收到智能提示说:“现在是凌晨0点10分,将在今早7点30分提醒您。”
相符:通过校验输入与预期的相符程度,查错或防错
表单上的各种校验,手机号、身份证号、邮箱地址等
顺序:按照自然顺序的工作流引导
一些较长的流程,如下单、售后等,会有工作流指引。
隔离:区域分割或重要数据分离,避免误操作
如软件设置的高级操作,Github的“危险区域”
复制:通过复制来完成相同任务,减少出错
继续上面的例子,GitHub要删除仓库时,需要手动输入仓库名称,以防误删
标示:醒目的样式差异来表达提示信息
如上图的删除仓库按钮的样式差异
警告:各种弹窗、提示信息
如上图的删除仓库提示信息
缓和:利用各种方法减免错误发生的伤害
微信的撤销和重新编辑功能,新版本还提供了“Re-edit”,多么贴心
有小伙伴可能会问,了解这些对测试有什么帮助呢?我们来对齐一下:测试的目的在于提升质量,而质量又是什么呢?质量是指产品满足用户需求的程度。这里有两层含义,一是软件需要满足用户需求,二是用户是评价软件质量的重要干系人。质量好不好,谁来评价很重要。由此可见,质量的评价既有客观的层面,又有主观的层面。
传统意义上的测试,关注的重点还是在客观评价层面:软件的功能是否完善、性能是否满足需求、线上缺陷多不多等。质量管理者对质量的主观评价层面往往缺乏关注,而用户或客户评价软件产品质量的出发点,很大程度上取决于主观印象。因此就产生了用户日益提升的体验需求、与质量从业者缺乏用户体验关注度之间的巨大鸿沟。
客观的说,测试并不是不关注体验,更多的是不知道该关注什么,或者不知道关注之后怎么办。具体可参考用户体验五要素,逐层的去关注用户体验设计的有效性、去验证软件的体验设计是否满足需求。
例如,在表现层主要关注视觉体验,这就要求软件能够保持一致的设计风格,能给用户留下整体一致的印象,测试就需要验证设计风格的一致性。大家可以根据不同层面的不同关注点,有针对性的设计体验相关的测试用例。
验证软件具备基础的体验能力后,测试人员不妨故意“犯傻”,反向验证一下软件的防呆能力。可参考以下清单进行尝试:
不遵守操作顺序
跳过关键步骤
尝试多次相同操作
删除或释放正在使用的资源
耗尽硬件资源
进行不被允许的操作
使用软件时杀掉进程
在请求数据时切换网络
暴力尝试:快速操作、连续操作、频繁刷新等
尝试薅软件的羊毛
删除关键信息并尝试恢复(防呆不防傻)
……
多关注用户体验,可以在实现了功能的基础上提升用户使用软件的幸福感,帮助我们留住用户。毕竟现在竞争激烈,不要在失去用户后才感慨,原来我们可以做的更好。
维基百科词条【防呆】:https://zh.wikipedia.org/wiki/%E9%98%B2%E5%91%86