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

共 3196字,需浏览 7分钟

 ·

2022-02-17 23:01

来源:圆小豆的美梦工场 

作者:于晓南


引子



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

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

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


知识诅咒



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


破局



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

怎样像用户一样测试,这道题考的到底是什么?考的是测试人员同理用户的能力,能否做到还原真实用户的使用场景,还原用户在使用产品时的真实心理。

说起来有点玄,但其实思路很简单。第一步就是先了解用户,只有了解用户的所思所想,才能知道用户会怎样使用软件;第二步是弥补测试人员和用户之间的断层。这有两层含义,第一层是让用户跟测试对齐,指导用户更好的使用软件;第二层面是让测试跟用户对齐,指导测试更有同理心。下面我们展开详细的讨论。

第一步:了解用户

  • 明确对象

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

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

  • 换位思考

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

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

  • 频繁沟通

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

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

第二步:弥补断层

  • 搭梯子

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

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

  • 建场景

让测试跟用户对齐,需要给测试补充真实用户的使用场景,可以采用场景法来分析用户的使用场景。还是以注册为例,真实用的使用场景可能是这样:注册→验证账号→登录账号→长时间未操作后重新登录。考虑到这样的场景,我们就不能要求用户在登录以后必须注销,或者下次登录的操作依赖于用户注销的状态。

我在测试工作中就遇到过这样的缺陷:用户登录后长时间未操作,但也未注销,再次登录提示:“登录失败,用户已登录。”还是上面的场景,在邮箱验证账号时,可能由于网络问题,没有收到验证成功的返回,而服务器端其实已经验证通过了,那么用户就会重复发送验证请求,服务器端处理后发现该链接已被验证过,于是返回:“验证失败,验证链接已失效。” 按照程序逻辑讲是没问题的,但以前端用户视角来看,就是验证链接不能用于验证,妥妥的功能缺陷。

比较理想的做法可能是,服务器端如能判断两次验证来自同一设备,直接返回 “已验证通过,正在跳转登录页……”。

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

  • 勤观察

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


结语



“从前一叶障目,现在我看见。

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

今晚8点,【冬哥有话说】“企业招聘专场推介会”,帮你找到称心如意的企业和岗位,锁定直播间,扫码报名~


浏览 43
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报