如何了解需求?
目录:
需求分析的痛点:
需求了解要做什么?
评审时要关注哪些方面?
在测试过程中,理解需求是第一步,也是最重要的一步。只有正确理解了需求,后面的工作才能顺利进行。
但在了解需求的过程中,经常会遇到各种各样的问题,比如说:
-
产品人员没有提供需求文档,或者提供的文档不清晰、不规范(有时候甚至用几句话描述一个复杂需求)
-
测试同学小明对某个需求不清楚,在公司里问了一圈都没有一个能准确解答他疑问的人(在一些互联网公司比较常见,产品人员流动性大,公司不重视文档记录)
-
产品组织需求评审,询问与会人员有什么问题时,测试同学小明一个问题都问不出来
-
产品给出需求文档后,测试经理安排给某测试同学小明了解需求。一段时间后小明反馈“文档已经看完了”,但测试经理询问“这次改了什么,为什么这么改,有哪些影响范围,什么时候上线”,小明都说不上来
-
需求开发完了,测试同学小明按照跟研发沟通的结果进行验证,测试通过后,产品人员(或客户)验收时却反馈这不是他们想要的,最后系统返工重做,浪费了人力物力,最后还失去了客户。后来公司内部追责时,小明被严厉批评
-
需求文档是否规范、全面(写的是否清晰、详尽)。便于节省沟通成本,使项目质量和风险可控。
-
易用性。所谓易用性,就是“易学习、易理解、易操作”。举几个例子如下,想看更多的话,可以加我的QQ群下载《黑盒测试框架》,里面有完整的说明。
-
功能是否有冗余,操作路径是否过深
-
需要进行说明的地方是否有说明?说明是否清晰易懂?
-
文字、图片、按钮排版是否合理
-
色调是否符合系统特色?效果是否统一
-
误操作提示
-
容错处理,
在需求了解时,多看看竞争产品是如何设计的,或者类似产品(功能)是怎么设计的,这有助于从设计角度去看待产品,也是一条有助于迅速积累易用性经验的建议。
如果公司中出现了上面提到的场景,往往是因为多方面原因导致的。本文不对此展开细述,有兴趣的同学可以加我微信私聊。接下来讲讲需求评审时我们要要做什么?
-
完整阅读需求,标记疑问(三种不同颜色,灰色代表没有疑问,红色表示有错误,黄色代表有疑问)。即使测试任务紧张,也要抽出时间来了解需求,不提前看需求,就会出现在需求评审时提不出问题来的尴尬局面。另外我习惯用excel表格把疑问整理下来,这样有助于知识传递。
-
书读百遍其义自见,多读几遍需求可能会自行解决一些疑问,多结合度娘解决一些术语性质的疑问
-
是否有原型图,新人加入团队时重点关注,多问问。
-
整个系统的流程图,发现逻辑缺失(整理资源竞争map、相关性map)
-
口头沟通的,邮件确认。
最后来说说评审时要关注哪些方面?个人认为最重要的就是多问问几个为什么。
-
需求背景,为什么要做这个需求,要解决什么问题?为什么要这么解决?是否有更好的解决方式,竞争对手怎么处理的这个问题?
-
了解需求上线时间。
**************胜者先胜而后求战,败者先战而后求胜!**************