产品经理干货:如何活用使用场景做产品测试?

标签: 产品经理宝典 | 发表时间:2013-10-13 09:47 | 作者:修泽
出处:http://blog.sina.com.cn/xwxiuze2008

  产品测试一般都是围绕需求为主的产品需求设计说明书PRD文档来展开测试的,针对每个功能点编写测试用例,去验证功能的正确性和完整性。这种方式在正常的开发上线进度下都不会有问题,相反是一种很好的验证功能需求实现的方式。但在敏捷开发模式或者因为赶进度的原因,造成产品测试时间非常紧的情况下,用这种方式就会有点捉襟见肘。
  以用户为中心的产品设计已经逐渐的深入人心,产品主题功能要能满足用户的某种诉求或者解决用户的某个痛点,也有说成是以用户痛点为中心的产品设计。在这种大背景下,产品开发完成后,如果测试时间非常紧,在不能保证产品没有问题但却必须要按时上线的时候,就必须保证产品在用户使用的场景下没有问题,也就是说优先保证用户使用产品的整个流程当中不会出现问题,这就是基于用户使用场景的产品测试法。
  在实际的测试过程当中,最常见的还是基于产品功能的测试,那基于用户使用场景的产品测试两者之间有什么区别呢?区别一是后者的测试范围更小,忽略了一部分产品后台功能的测试或隐性的功能测试,即只是测试了表面操作性的过程,没有测试底层的功能;区别二是后者的测试是把产品功能转化成实际用户使用场景下来测试,这就要求测试人员要从普通用户的操作角度出发,而不能受开发人员的影响,以一个初次使用产品的用户角度,来验证产品的功能是否可以在使用过程中提供正常的服务。
  这里需要注意的一点是,在时间进度允许的情况下,还是要基于产品功能的测试,以求测试可以覆盖到产品的方方面面,确保产品可以提供完善的服务。本文所阐述的基于用户使用场景的产品测试都是建立在测试时间非常紧的前提下的,因为本身这种测试方法因为测试的不够全面,有一定的风险性在里面,对产品而言不一定是好的,只是为了保证产品的发布时间,而采取的一种较为折中的测试方法。这种测试方法的使用需要有以下两个要素,否则最好还是做全面的产品功能测试。

  测试时间非常紧

  其实这种场景非常的常见,项目进度安排了之后,往往因为需求分析的时间超长了,或者开发的时间延误了,导致最后留给测试人员的时间非常少,这时如果必须保证项目上线进度的话,就无法完成全面的产品功能测试,只能优先测试用户操作流程当中所需使用的各个产品的功能模块的流程。有的时候也是因为测试资源的不足所导致的测试时间紧迫,测试人员在这些情况下可以考虑基于用户使用场景的测试,但必须与项目经理或者主管领导说明清楚,是为了确保项目进度而采取的优先测试用户使用产品流程的功能。

  从傻瓜用户的角度测试

  基于这种方式的测试,测试人员就必须从用户的角度出发,而不是从开发人员或者产品经理的角度。也即测试人员必须保持相对的纯粹性,可以参加产品功能需求的review,但就不应该参加开发人员的系统设计review了,否则会受到开发人员实现方式的影响,而导致后续的测试不准确。应该是在保证理解产品功能需求的基础上,尽量从普通用户的使用场景出发,找出使用过程的问题,以便开发人员优先解决,这时候测试人员也不需要和开发人员去讨论问题,只需告诉问题发生的场景即可,以便尽可能的不受外界信息的影响。
  在上述两个要素满足的条件下,测试人员还要抛开自己的计算机专业素养,把自己当成一个大众化的用户,以使测试的结果更接近真实的使用场景。由于该种测试方法并未覆盖产品的全部功能,会造成产品发布后有一定的风险性,既然知道有这样的风险,就需要去尽量的避免或者降低相应的风险,这就需要整个产品团队的配合,也需要测试人员自身有一套完整的测试体系。
  开发人员的自测和Code Review
  开发人员在开发完成之后,需要有一轮自测,以降低代码风险和功能缺陷,减少后续测试验证和改BUG的时间。自测的过程当中,需要与产品经理的需求相结合,以实现第一轮的功能验证,一旦出现问题及时解决。开发人员也是最熟悉底层结构的人员,一些底层的功能问题可以在自测过程当中去发现解决,尽可能保证没有大的问题遗留到测试阶段。自测也是开发人员自身能力水平提升的一个很好的机会,提升代码质量的同时,也是提高对自身编写代码责任度的一种方式。自测是需要基于开发人员自身的能力水平的,此外还可以借助团队的配合,如敏捷开发模式当中就很强调开发团队内部的Code Review,一个开发人员编写的代码,由另外两个经验较深的开发人员来共同把关,这样也可以在很大程度上减少代码缺陷,尽早的发现问题。

  从用户使用的角度去测试

  基于用户使用场景的测试不能保证产品没有问题,但必须保证产品在用户使用过程当中没有问题,这就要求测试人员必须从用户的角度出发,真正按用户的操作流程去操作测试产品的功能。再就是把编写测试用例的时间,留出来用于理解产品的功能需求,以便在测试的过程当中及时发现不满足需求的功能点,因为这类功能点在测试的时候并不会出错,但却不是需求说明书中所设计的那样,这就需要测试人员充分的理解需求。也不是说测试用例就不需要编写了,而是在测试的过程当中,依赖测试工具去记录测试的过程,后期再来整理这部分用例。因为这个测试阶段结束了之后,后续还是要继续验证产品的整体功能的,包括底层的功能,这时可以一起编写测试用例文档。
  从用户的使用场景出发去测试需要测试人员对用户使用产品的方式有一定的了解,比如说财务系统和普通的业务系统在操作的时候差异就比较大,原因是财务系统受国外成熟财务系统产品的影响比较大。这需要测试人员去更多的了解用户的使用,当然这个过程也还是要基于产品自身的功能结构设计,不排除有一些需要培养用户使用习惯的功能,这种功能就需要产品经理做一些特别的说明,以使测试人员理解产品设计的意图,最好可以提供一份产品操作使用手册。
  前面也都提到了这种测试方式是存在风险的,这就要求在发布上线之后要继续进行剩余功能的测试,而不是测试过程就终止了。在后续的测试过程当中,可以一并验证之前遗留的问题,并在接下来的一个快速迭代中上线解决掉,这样就可以将产品的功能风险降到最低,使产品提供稳定的服务。
  基于用户使用场景的测试目前应用的还不是很多,在创业型产品的快速迭代中,或者敏捷开发模式下的敏捷测试当中,会有一些应用。这种方式虽然有一定的缺陷,但却是一种非常好的备选方案,可以在保证项目进度的情况下,也能保证用户在使用产品的时候不出问题,使产品在用户手上没有问题,这也是发布产品的一个目的,符合产品发布的要求。

文章来源:IT民工


  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [产品经理 干货 活用] 推荐:

产品经理干货:如何活用使用场景做产品测试?

- - 一个产品经理的博客...
  产品测试一般都是围绕需求为主的产品需求设计说明书PRD文档来展开测试的,针对每个功能点编写测试用例,去验证功能的正确性和完整性. 这种方式在正常的开发上线进度下都不会有问题,相反是一种很好的验证功能需求实现的方式. 但在敏捷开发模式或者因为赶进度的原因,造成产品测试时间非常紧的情况下,用这种方式就会有点捉襟见肘.

产品经理干货:可用性测试的那些事

- - 人人都是产品经理
可用性测试是指通过对典型用户实施测试来对产品或服务做出评价. 在一次典型的测试中,用户要完成一系列典型任务. 与此同时,观察者会在一旁观察、倾听、做笔记. 可用性测试的目的就是为了发现可用性问题,收集定性和定量的数据,并评估用户对产品的满意度. 可用性测试有助于设计和研发团队在产品成型之前发现问题.

产品经理

- - 人月神话的BLOG
再谈下怎样能够算得上一个合格的产品经理,一个人不是说你能够有产品构思,能够画点原型,能够做团队和项目管理就是产品经理. 苏杰原来有本书叫《人人都是产品经理》,看了后大家可能会觉得做一个产品经理是挺容易的一件事情,但是自互联网提供和设置了大量的产品经理岗位后,产品经理这个词基本就烂大街了. 我们如何来界定一个产品经理,如果简单点来讲可以理解为 根据自己长期的项目和运营实践,通过自己的敏捷洞悉能力和分析能力,能够将当前的市场需求或潜在的市场需求转化为具体的产品需求,并能够核心的定义产品功能模型和价值输出,同时能够通过项目和团队管理的能力,凝聚一个小组形成一个真正的团队,将自己的产品构思付诸于最终产品实现的人.

产品经理好与坏

- lnsoso - 随心所记 - 生活中的dodo
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- 张金龙 - 所有文章 - UCD大社区
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理好与坏

- abcd - 所有文章 - UCD大社区
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- Neglect - 坏脾气的小肥
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理“玩”数据

- - 一个产品经理的博客...
  产品经理生来就是要解决问题的. 那如何才能更好、更高效地解决问题?首先要求我们能发现问题,数据分析就是一种常用的发现问题的手段. 通过数据定位问题,然后用设计方案来尝试解决问题,之后再用量化的数据指标来评估问题是否解决了,解决了多少. 通过迭代优化,问题就能够得到较好解决.   本文结合自己在在登录产品的体验优化中积累的一些实战经验,重现过程中的设计点滴,有效果明显的方案,也有效果不明显的优化尝试,最后将总结一些通用的设计思路.

好的产品经理,差的产品经理

- - Xiaoxiao's Weblog
本文转载至 译言网 作者: Ben Horowitz. Ben Horowitz这篇不朽的杰作诞生于1996年,但时间的久远丝毫不影响其对当前的警示作用. 彼时,作为Netscape产品管理部门经理的Ben,没有假大空地介绍产品经理的角色和责任,而是很直观地对比了一个好的产品经理和差的产品经理.

一个谷歌产品经理眼中的产品经理

- - 互联网分析
我在创业公司已经呆了好一阵子了,我发现招聘这个事儿在大公司和创业公司还真是截然不同. 在雅虎搜索的时候,我们一直是持续的进行招聘的. 我一周会进行大概5-8次的面试. 简历、面试、offer,总是一个接一个,不间断. 现在我已经不做招聘经理的事儿了,我在创业公司只负责招很少一部分的产品经理. 但是总有人在招产品经理,而我也总是面试团队的一员.