需求评审,测试人员应该发挥怎样的价值?两分钟让你不再懵逼

前言

大家好,我是IT小学生蔡坨坨。

前些日与朋友聊天,谈及需求评审,作为测试人员,我们应该在需求评审会议上做些什么?

《需求评审,测试人员应该发挥怎样的价值?两分钟让你不再懵逼》

记得第一次参加需求评审,傻傻的过去坐着,然后听别人巴拉巴拉说半天,自己一头雾水、一脸懵逼,会后又花大量的时间看需求,等到提测的时候可能需求都没怎么搞明白……

《需求评审,测试人员应该发挥怎样的价值?两分钟让你不再懵逼》

那么问题来了。怎样能够让需求评审更高效呢?作为测试人员又如何在其中发挥价值呢?

首先参与评审的可能是产品、开发、测试,时间一般控制在1个小时左右,如果过长,如两三个小时可能就不是很高效,如果过短,对于稍微大一点的需求一些详细的点就可能没有考虑到。

需求评审

会议前:

进行需求评审之前,产品经理一般会给到需求相关资料,像我们公司会由产品经理建一个jira单,单子上附有客户背景、客户需求、产品方案、PRD、原型图等。我们需要提前阅读相关文档,深刻理解需求,对于有疑问的点提前标注出来,然后在开会的过程中积极地去参与这个会议,抛出疑问点。除了关注功能要求,还需要关注数据类型、接口定义、性能要求、安全性等,这个根据具体业务进行评估,像我们公司是做电子合同业务的,就会考虑文件缩略图频繁请求、加盖印章过多等是否会导致性能问题。同时还需要考虑一些隐性需求。

会议中:

  1. 需求澄清的时候不要在会议上面玩手机或者干其他事情,因为如果需求理解不深刻,后面测试相关的工作就很难开展。如:不能正确编写测试用例,找不准测试点,业务相关知识串不起来等。
  2. 需求中产品设计不合理、很难理解、逻辑有问题、以及可能影响原功能的地方,对于这些点我们要抛出疑问进行澄清,从而推动产品进行修改,最终达成一致。
  3. 需求中没有被量化的点,例如:某个功能涉及的字段类型、长度和规则,如:标题栏位类型为普通文本,长度为100个字符、手机号栏位应该符合规范,首位为1,11位数字。为什么需要量化?因为只有量化之后,才有利于测试后续用例的编写,测试才有可能用等价类、边界值进行用例设计,开发才能进行一些数据库字段的设计(如varchar(11)、int、bigint)。
  4. 思考需求中的测试点,影响我们做测试的地方让产品经理给出说明,比如这种异常情况怎么处理?有多少种状态?状态之间如何转化?总之就是影响我们测试的地方都要让产品经理给出说明,这样给我们后面写测试设计和测试用例扫清障碍。

会议后:

  1. 评审结束之后,需要把一些待确认的地方整理并发出来。
  2. 经过评审会议的讨论,可能会有需求点发生了变更,这时就需要让产品将最新的PRD整理完整重新发出来,再对修改的地方进行确认。

成果

经过以上需求评审,你会得到什么?

  1. 符合软件测试的原则,“测试应该尽早进行,最好在需求阶段就开始介入,因为最严重的错误不外乎是系统不能满足用户的需求”,从而在产品初期帮助整个团队避免很多的错误。
  2. 充分理解被测需求,深刻熟悉被测业务,为后续测试工作的开展、测试用例的编写扫清障碍。
    原文作者:IT小学生蔡坨坨
    原文地址: https://www.cnblogs.com/caituotuo/p/16282945.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞