标准研发流程

发布于 2022-10-18  778 次阅读


之前做研发的时候,因为我刚入职,需求都是由我的导师和Leader分配的,所以给到我手里时只需要我设计方案并给出工期,没有关注标准的需求研发流程。

此时,我已转岗至业务中台测试岗,在这边有标准的研发流程,我想是可以参考的,因此特意记录。

 

一、标准研发流程图

二、标准研发流程说明

1.角色关系

产品和研发的关系

  • 产品要具备独立性,独立成立产品团队/部门,独立开展工作;
  • 产品负责需求,需求决定了开发实现什么,故相关开发人员(负责相应功能模块的开发人员)一定要参加需求评审会议以便及时了解需求;
  • 开发人员最怕什么?十个有九个会说需求又变了,所以产品对于需求变更一定要慎重,通过建立起相应的需求管理规范和制度来做到无随意的需求变更,需求变更后干系人都能及时得到通知;
  • 开发人员要彻底理解需求,这是进行开发的前提;开发人员要多和产品人员沟通,及时消除对于需求的误解和疑惑;

产品和测试的关系

  • 测试人员(一般都会开展交叉测试,所以都参与)一定要参加需求评审会议以便及时了解需求;
  • 测试人员依据需求文档设计编写出测试用例后一定要进行测试用例评审并一定要邀请产品人员参会;因为产品人员对需求是最了解的。
  • 需求确认变更后测试人员要及时得到通知并尽快更新测试用例并根据实际情况是否进行测试用例评审。

测试与研发的关系

  • 测试要具备独立性,独立成立测试团队/部门,独立开展工作;
  • 测试人员要懂代码(看懂代码是基础,会写代码更好),懂代码是和开发团队的沟通利器,也是开展自动化测试的基础。当今语言很多,个人认为优先掌握Java或者Python;
  • 测试人员要有一定的沟通能力,报告缺陷时请描述清楚但去除不必要的测试步骤,也别忘了描述测试环境等相关信息,可以附带缺陷出现的截图,日志文件,甚至录制一段重现缺陷的视频都是让开发人员迅速重现缺陷的很好的办法;
  • 测试人员在报告缺陷时如有把握,可以给出解决方案,这样的测试人员我相信开发人员一定很喜欢。

2.会议类型

需求评审&需求澄清会议

产品:主持人;需要说明需求背景、需求内容、需求目标、需求完成的时间点,并通过会上讨论完善需求或者调整需求。

研发:在与会前需要大致了解需求,会上以自己对产品or业务的理解,逐一与产品、测试确认需求点,对需求不合理的地方提出质疑,可要求产品重新评估。研发人员需要更关注需求实现层面,例如实现难度、实现方式是否合理等。

测试:在与会前需要大致了解需求,会上以自己对产品or业务的理解,逐一与产品、研发确认需求点,对需求不合理的地方提出质疑,可要求产品重新评估。测试人员需要更关注需求所带来的影响,例如是否会影响线上业务、是否存在潜在风险点等。

注:会议可分三阶段:会前、会中、会后;

  1. 会前要求各方对需求有大致了解。
  2. 会中要求各方落实需求细节,并记录待修改、待确认的问题,不可有遗漏点。
  3. 会后要求各方对会议提出的问题进行跟进,产品及时更新需求Tapd文档,研发及时更新需求技术方案,测试及时调整设计用例。

需求阶段结束、进入方案阶段

需求评审&需求澄清会议

 


她喜欢所以就做咯