同理心:从测试的角度来总结分析产品设计
相关评论
来源:
作者:
发布时间:2018-05-13 10:11

产品经理在项目开发中扮演的是一个连接者的角色,连接的前提是要熟悉连接对象即兼容对方,善于从对方的角度思考问题。本文将从测试的角度来总结分析产品设计,以此来提升产品设计全面性。

同理心:从测试的角度来总结分析产品设计

在苏杰大神的博客文章中有这样一个观点:

产品新人如何快速上手的方法之一是写测试用例。

测试用例是从测试的视角写的产品描述。测试与产品的逻辑不同,产品抓大放小,测试就是要想清楚各种边边角角。

所以,如果团队正好没有TC,你来写一遍,保证对产品的各种细节都很熟悉,也会知道背后用的技术,因为各种限制而造成的各种坑。

一、关于软件测试

  • 从测试方法来分:软件测试分为黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手工测试、自动化测试。
  • 从测试阶段来分:软件测试分为需求测试、单元测试、集成测试、系统测试、验收测试。
  • 黑盒测试也叫功能性测试,在软件测试过程中大多采用此方式。我所说的产品经理懂测试,针对的即是功能性测试,从功能性的角度做产品的需求文档,遍历尽可能多的功能场景。一定不能让开发和测试找到你的漏洞,那将是产品经理最尴尬的时刻。

    有数据表示:

    在许多失败的项目中,70%~85%的返工是由于需求方面的错误导致的。

    二、限制边界值

    如果没有限制输入框的长度,专业的测试分分钟可以把开发认为没问题的程序搞挂。

    因此对输入框的长度限制,是一个产品最底层的功能,我想这也是产品经理的基本素养。进一步的要求是对可输入字符类型的限制,此项不至于影响到功能,但属于产品最基本的友好性需求。

    下图是作者好不容易找的一个反面例子:

    同理心:从测试的角度来总结分析产品设计

    数值「0」是开发容易忽视的边界值,在很多场景中0值其实是没有意义的,比如金额为0元、数量为0等。自己的亲身经历:之前做过一个资金分配的功能,由于PRD没有说明字段的规则(以为开发小哥哥用脚想想都会明白),然而在做功能验收的时候,我成功给好友分配了0元。。。

    对于这些字段的规则,其实没有必要在文档上一一标注,因为很多页面的字段其实是重复的,这个方法也很容易漏掉一部分字段。一个很好的工作方法是:在全局规范中建立字段规则表。这个方法让我想起了:大学编程的时候,会统一将全局变量的定义集中放置。

    同理心:从测试的角度来总结分析产品设计

    作者抛出一个输入框对空格的处理的测试用例供大家思考:

    1. 前面存在空格
    2. 后面存在空格
    3. 前后都存在空格
    4. 中间存在空格

    二、遍历异常逻辑

    正常流程只有一个,异常流程却异常的多。在很多PM的PRD中,仅仅陈列了正常的业务流程。

    很少有开发是会替产品考虑异常逻辑的,所以为了不给自己挖坑,在写PRD的时候,就要将所有的异常流程都描述清楚,我想在需求评审的时候会更容易通过,也会在开发的眼里树立权威。

    有人说,无反馈是产品大忌。我想说,反馈不完全也是产品不专业的体现。对于特定事件的反馈,既然有成功的结果,必然会存在对立面——失败。对于这些事件的总结其实很容易找到规律,很多优秀的PM都会整理一份交互设计自查表,然后会不断的更新迭代。

    同理心:从测试的角度来总结分析产品设计

    善于总结是一个优秀学习者的必要品质,在项目经历中总结积累遇到的异常情况。有句话这样说:

    “你现在经历的每一件事,都会在未来某一时刻用上”。

    登录注册可能是大多数PM童鞋的处女级产品功能,根据我个人的经验:如果没有从零到一将这个需求落地,一定是存在认知漏洞的。

    我说一个场景,看大家有没有考虑到:手机号验证码输入框在同一个页面,在手机号无误、验证码输入正确的情况下,然后更改手机号(手机号格式合法),提交之后应该如何反馈?

    三、关联性的问题

    在项目中,大多数功能模块往往不是独立的,一般存在交集或者需要进行模块间的数据交互。因此一个模块如果发生了需求变更或者数据丢失,就会影响到相关联的功能模块。

    曾经做过一个项目,由于平台新增了直营店功能,之前设计的订单详情就不适用了,需要融合新需求,财务管理模块也要做字段的扩展。