写点什么

像用户一样测试:打破知识的诅咒

用户头像
QualityFocus
关注
发布于: 2020 年 12 月 28 日
像用户一样测试:打破知识的诅咒

引子:先来玩个视觉小游戏,请在下图中找到隐藏的五角星。



没找到的朋友,答案在文末。请看完答案再回到这里。

现在我们回看上图,是不是很容易就找到五角星,甚至第一眼就看到它了?


知识的诅咒


“有些事知道了,就再也回不去了。”


知识诅咒,指的就是一旦我们自己知道某样东西,就会发现我们很难想象不知道它的时候会是什么样子。 我们的知识“诅咒”了我们。 对于我们自己来说,同别人分享我们的知识变得很困难,因为我们不易重造我们听众的心境。


那这件事和测试有什么关系呢?我们看一个典型的测试用例是什么样的:



按照用例执行,假设执行结果符合预期,我们就可以验证系统的注册功能确实是正常的,新用户可以注册并登录。但问题在于,真实的用户并不是这样使用软件的。


下面让我们来看看真实用户是怎么想的(小蓝字)、怎么做的:

  • 打开网站,找到注册按钮,点击进入注册页,如①,好像没有必填哎

  • 输入昵称,提示昵称重复,如②,样式真不讲究,差评~

  • 点击注册,提示手机号不正确,如③,手机号必填?随便输一个

  • 输入手机号,没填验证码,点注册,如④,密码忘填了

  • 输入密码,点注册,如⑤,验证码也要填啊,早不说,哎麻烦死了,算了不注册了!


注:图片来自真实的互联网软件产品,截图日期 2020 年 11 月 25 日


我们来回顾一下上面这个过程:用户每一步都是按照软件提示做的,但并没有得到想要的结果,在注册过程中负面情绪不断累积,直到最后一根稻草压上来,最终放弃了使用。但用户的需求还在,他会找到注册功能好用的竞争对手的软件,边开心的使用,边在心里暗暗下决心:再也不用那个破网站了。


当测试执行完用例,确认注册功能没问题的时候,用户已经在注册完成前就跑了。究其根本,测试人员在测试时使用的还是“测试心智”,对被测软件的熟悉和了解是内化在心里的,测试时主要发挥的是测试领域的专业技能;而用户在使用软件时,是不会带有“测试心智”的,不会预知软件的表现,注册的过程对新用户来讲是全新的体验。测试人员和真实用户在使用软件上的差异是很明显的,这也是为什么尽管经过大量测试,用户仍然会吐槽软件难用的主要原因。


看看在小猪佩奇里怎么解决这个问题。猪爸爸是跳泥坑届的世界冠军,他对佩奇说:“要想跳好泥坑,秘诀是与泥坑融为一体。要想获得跳泥坑冠军,就要学会像泥坑一样思考!” 所以在准备阶段,猪爸爸并没有一上来就疯狂的练习跳泥坑,而是花大量的时间在思考,到底怎样才能和泥坑融为一体。



测试人员想像用户一样测试,要学会像用户一样思考,打破知识的诅咒,真正带着初心的使用软件。这并不容易,但也是有迹可循的。这也是目前测试领域关注度相对较少的、但却是打造完美软件不可或缺的重要一环。


破局


“愿你出走半生,归来仍是少年。”


怎样像用户一样测试,这道题考的到底是什么?考的是测试人员同理用户的能力,能否做到还原真实用户的使用场景,还原用户在使用产品时的真实心理。说起来有点玄,但其实思路很简单。第一步就是先了解用户,只有了解用户的所思所想,才能知道用户会怎样使用软件;第二步是弥补测试人员和用户之间的断层,这有两层含义,一层是让用户跟测试对齐,指导用户更好的使用软件;另一层是让测试跟用户对齐,指导测试更有同理心。下面我们展开详细的讨论。


第一步:了解用户

明确对象


首先澄清一下测试的目标,测试的终极目标并不是提供零缺陷的软件,而是提供好用的软件。只有软件好用,用户才会用脚投票。好用是个主观评价,谁来评价很重要。测试人员需要明确软件真实的用户到底是怎样的群体,他们评价软件好用与否的标准是什么。


明显的,软件好用与否取决于很多因素,产品是面向 C 端、B 端还是 G 端?产品形态是小程序、App 还是平台网站?产品的用户和客户评价标准是否一致?这都影响用户和干系人对软件的最终评价。因此,充分的需求背景分析和用户调研不仅仅是产品经理需要考虑的事情,也应该是测试人员关心的范围。


换位思考


在明确对象之后,我们大概率能知道用户群体是谁,他的典型画像是什么样的,这也是我们进行换位思考的基础。还是以登录为例,假设我们目标用户的特征是:高知宝妈、价格不敏感、时间宝贵、愿意为知识和体验付费。这时采用移形换影大法,我就是这位宝妈,我希望注册过程可以尽量简洁,让我能花较少的时间完成,同时也尽量优雅,从界面到操作都浑然天成,注册的过程本身就是一种享受。


有了这个视角,易得出优秀软件的一个通用标准,即:让用户在使用软件时,尽可能感受不到软件的存在,好像世界本应如此,自然而顺畅。具体可参考用户体验三大要素及相关资料:别让我等、别让我想、别让我烦。

频繁沟通


频繁沟通有助于更好的了解用户,建立用户同理心。当我们通过倾听用户获得更多的细节时,就更容易了解用户的所思所想,了解尴尬的现状和切肤的痛点,从而更容易做出满足用户真正需求的决策。


建立一个负担不重的沟通机制是至关重要的,让用户在想沟通时能够随时找到沟通的渠道。另一个重要的点是,要真正的倾听,既不能盲从也不能盲不从,太南了。怎样避免鸡同鸭讲,真正听出用户的弦外之音,我也还在探索。但相信建立意识是艰难的第一步,抬腿迈步 ing~


第二步:弥补断层

搭梯子


让用户跟测试对齐,可以通过简明的文字或图形指引。如下图:我们很容易看出,这个流程共 7 步,当前在第 3 步。在测试时,需要检验软件功能针对长流程的指引是否完备且准确。



搭梯子的另一种方式是,建立基于业务的用户文档。言外之意是,写出用户能看懂的、贴近用户使用场景的使用手册。哪怕我的功能是提供一个接口,我也不应该仅仅贴出接口文档,而更应该补充该接口的使用场景:在什么情况下使用接口,应该以什么频率调用,最多支持多大的并发量,各字段枚举值所代表的具体业务含义是什么,不同的用户调用接口时的注意事项……

建场景


让测试跟用户对齐,需要给测试补充真实用户的使用场景,可以采用场景法来分析用户的使用场景。还是以注册为例,真实用的使用场景可能是这样:注册→验证账号→登录账号→长时间未操作后重新登录。考虑到这样的场景,我们没理由要求用户在登录以后必须注销,或者下次登录的操作依赖于用户注销的状态。我在测试工作中就遇到过这样的缺陷:用户登录后长时间未操作,但也未注销,再次登录提示:“登录失败,用户已登录。”


还是上面的场景,在邮箱验证账号时,可能由于网络问题,没有收到验证成功的返回,而服务器端其实已经验证通过了,那么用户就会重复发送验证请求,服务器端处理后发现该链接已被验证过,于是返回:“验证失败,验证链接已失效。” 按照程序逻辑讲是没问题的,但以前端用户视角来看,就是验证链接不能用于验证,妥妥的功能缺陷。比较理想的做法可能是,服务器端如能判断两次验证来自同一设备,直接返回 “已验证通过,正在跳转登录页……”。


还原真实用户的使用场景,有助于测试人员设计出更符合用户特征的测试用例。以后在写测试用例的时候,还可以加上一个用例分类:用户场景测试



拓展阅读:《肥皂剧测试》,作者史亮

勤观察


测试人员应培养敏锐的观察力,在日常时时观察用户的特质,以及用户在使用软件时的微小反馈。不愁没有用户,我们可以随机从同事中抽取非研发部的伙伴来帮忙快速验证,或者在需求验收时收集并记录大家的反馈。任何一个细节都可能成就一款产品,也可能失去一部分用户。以认真细致著称的测试人员,如能投入更多精力在贴近用户的测试中,这将为软件质量的评价带来非常积极的影响。


结语:“从前一叶障目,现在我看见。”


附:怎么样,找到五角星了吗?它在这里。



发布于: 2020 年 12 月 28 日阅读数: 19
用户头像

QualityFocus

关注

ThoughtWorks 资深软件质量咨询师、培训师 2019.06.28 加入

微信公众号:圆小豆的美梦工场 自我介绍:https://qualityfocus.club/yxn 博客:https://qualityfocus.club 知乎:https://www.zhihu.com/column/TestFocus 简书:https://www.jianshu.com/u/2a06e4d01115

评论

发布
暂无评论
像用户一样测试:打破知识的诅咒