zoukankan      html  css  js  c++  java
  • 从BRD到上线:一个需求的完整生命周期

    需求完整生命周期


    产品PRD评审:

    1. PRD评审邮件,评审是否通过,是否有补充点、待决议点,如果场景考虑不全或者主流程不通,评审不通过打回后重新提PRD。
    2. PRD中细节描述要清楚,比如特殊场景的处理,产品容错处理,做到开发人员可以以PRD为准。PRD的细节缺失会造成开发人员的开发场景缺失,测试人员测试场景缺失,大概率的出现线上BUG。此点需要产品、研发、测试的共同努力,争取将BUG消灭在PRD评审阶段。避免出现如下场景:测试完成后准备上线时产品发现需求考虑不全,需重新讨论需求;提测后产品发现有场景遗漏需要补需求;这些场景均会造成测试资源、开发资源的浪费。
    3. PRD评审通过后输出PRD评审报告。


    研发人员提测:

    1. 提测前执行测试人员提供的冒烟用例,保证100%通过。
    2. 根据实际情况进行小组codereview 或者结对codereview,review通过后方提测。
    3. 提测单上附属codereview通过截图、接口测试附属接口名称#方法#本地测试入参、涉及应用、应用代码地址、分支、修改点。


    测试人员测试:

    1. 在研发提测前准备好测试用例,其中涉及到主流程的标记为冒烟用例。
    2. 与研发人员、产品经理、项目经理一起评审测试用例,并输出测试报告,后将测试用例提供至研发人员。
    3. 研发人员提测后,测试人员进行冒烟,冒烟通过后继续执行其他测试用例,冒烟失败则打回提测单至研发人员。
    4. 测试人员在测试环境执行完毕所有测试用例后,进行分支预发,分支预发测试完毕后主干预发,主干预发测试完成后输出业务方验收报告。
    5. 业务方验收完成后,进行上线。上线后进行线上验证,输出测试报告。

    完整流程中共有11种文档输出:

    1. BRD(Business requirements document)
    2. PRD(Product requirements document)
    3. PRD评审报告
    4. PDD(Product design document)
    5. PDD评审报告
    6. 测试用例 (Test Case )
    7. 测试用例评审报告
    8. 提测单
    9. JIRA单
    10. UAT验收报告
    11. 需求测试报告
  • 相关阅读:
    跃迁方法论 Continuous practice
    EPI online zoom session 面试算法基础知识直播分享
    台州 OJ 2648 小希的迷宫
    洛谷 P1074 靶形数独
    洛谷 P1433 DP 状态压缩
    台州 OJ FatMouse and Cheese 深搜 记忆化搜索
    台州 OJ 2676 Tree of Tree 树状 DP
    台州 OJ 2537 Charlie's Change 多重背包 二进制优化 路径记录
    台州 OJ 2378 Tug of War
    台州 OJ 2850 Key Task BFS
  • 原文地址:https://www.cnblogs.com/emma-lucas/p/10673827.html
Copyright © 2011-2022 走看看