开发者社区 > 博文 > 提升提测质量之研测共建
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

提升提测质量之研测共建

  • il****
  • 2023-11-03
  • IP归属:北京
  • 188浏览

    一、序

    日常研测工作演绎


    你是否也有同样的困惑?

    跟进的需求,就在提测前一秒,被告知不能如期提测了,研测计划被打乱;

    提测的功能,犹如遇到不好的购物体验,缺斤短两,与prd预期不符;

    产研测三方需求理解不一致,临时组会讨论,出临时解决方案;

    等等。。。


    你是否也遇到了以下的挑战?

    1.时间约束:敏捷开发周期较短,迭代速度快,使得测试人员很难在可用的时间内彻底测试软件;

    2.回归测试:在不断地迭代中,系统功能大大小小的功能点,多如牛毛,如何能准确确定回归范围?

    3.测试自动化:敏捷开发通常需要高度的测试自动化来跟上快速的开发节奏,测试case的开发和维护,都需要投入大量的时间和精力。


    面对这些困惑、挑战,我们该如何去推动、提升研发的提测质量呢?有没有前置的动作,能够提高提测质量呢?


    二、提测质量研测共建

    软件项目中,影响产品质量的因素很多:需求质量、设计质量、编码质量测试质量,甚至发布时的配置,都会影响最终的交付质量。提测前的工作占比高,为核心环节,过程、质量的好坏,直接决定最终的结果。

    1. 责任与使命

    参与者的参与度、责任感,都会直接影响整个产品质量:

    目标管理:"心之所向,行之所往,未来可期",在软件项目中,也同样适用,有明确的目标,即把工作做好、做极致、做完美,才会有好的结果。

    越位思考,本位做事:每个参与除了要考虑岗位职责范围的工作,还要将自己置身于整个过程、整个链路中,思考上、下游衔接点,做好无缝衔接。

    拥抱变化:软件研发管理中,变化是常态,参与者要善于调整计划,适应变化。

    自我提升:在工作中,不断地提升自身的技术能力,拓展业务知识,提高沟通和协作能力,通过持续的提升,提高工作效率,提升工作质量。


    2. 项目管理

    2.1 资源管理

    人员是最为重要的项目资源,进行工作安排时,应充分考虑以下几点:


    人员的责任心够么?能够支撑他完成这项任务么?

    人员能力与项目所需能力是否匹配,会小马拉大车么?

    人员对业务是否了解?是否能把握当前需求么?

    人员的工作量是否已饱和?是否能消化当前需求?


    2.2 流程管理

    在每个迭代实施过程中,形成标准化的协作流,如下图:

    在践行标准的流程下,还有些细节点可以帮助提升提测质量:

    2.2.1 需求评审阶段

    在敏捷管理中,需求评审是一个关键环节。需求是项目实施过程中共同的标准参考,需求的质量很大程度上决定了最终的交付质量,研测要在评审前,做充分的思考:

    1. 评审前,研测人员对需求进行预习,准备待确认问题,对需求问题进行信息拉齐;
    2. 抽象:从宏观层面,了解业务背景,理解要解决的业务痛点;
    3. 具象:了解需求功能,了解相关功能的上下文;
    4. 抽离:对功能进行推理、演化、扩展,提出需求未明确的场景,进行补充确认;
    5. 控场:对于歧义较大、需求缺失信息较多的情况,合理拒绝。
    6. 对评审的问题,形成待办,落实责任人。对问题进行跟进,对结论进行同步。


    2.2.2 研发设计评审阶段

    在敏捷管理中,设计方案评审是一个重要的环节,旨在确保项目的设计方案符合项目需求、技术标准,准确评估影响范围。

    1. 研发人员需要编写清晰、具体、可验证的设计文档,数据库设计,接口文档,以便在评审过程中更好地理解和评估设计方案;
    2. 测试人员评审前对相关文档进行预习:包含但不限于以下文档,设计文档、依赖的内部、第三方、企微接口文档、数仓表、上下游功能等;
    3. 测试人员准备待确认问题,不限于设计问题,也可包含业务场景补充、影响范围补充;
    4. 测试人员提合理的物料要求:比如造数、日志关键字支持,在测试环境进行冒烟测试,配置依赖的配置信息,通过业务流完成冒烟测试;
    5. 测试人员,可以提前识别复杂造数场景,与研发沟通,协商采用脚本或其他工具提前完成;
    6. 研发技改需求,研发为了追求完美,方案可能会改多版,改动随意,要求明确改动点,影响范围,回归范围;

    2.2.3 研发开发、自测阶段

    1. 频繁沟通,保持频繁、及时、有效的沟通,确认需求理解一致性,确保对项目的需求和进展有清晰的理解
    2. 对业务背景及需求理解透彻,避免开发方向性错误;
    3. 合理设计方案,具备灵活扩展、足以应对小的需求变更的能力;
    4. 合理工作拆分,尽量减少交叉工作及相互依赖;
    5. 合理评估工作量,细化工作内容,规避工期对质量的影响;
    6. 合理设计自测场景,提前了解测试用例,提高自测意识及覆盖度;
    7. 全面评估及约束影响范围,避免对已有功能产生不可预知的影响;
    8. 开发细节过程可追溯,避免在测试阶段遗漏;
    9. 代码评审,通过评审,帮助团队发现签潜在的问题,提高提测质量。


    2.2.4 测试用例设计及评审阶段

    1. 测试用例前置,帮助团队发现潜在的问题,避免在后期才发现问题,从而降低修复问题的成本
    2. 充分理解需求,了解业务的痛点,从业务层设计,全面覆盖业务场景;
    3. 理解技术实现过程,了解数据存储及数据处理逻辑,多考虑可能的异常情况,对数据的不同态进行考虑设计;
    4. 自动化测试用例资源盘点,复用自动化用例,提高测试效率,扩大测试回归范围,保证测试质量;
    5. 测试物料准备工作前置,环境的构建,数据的准备,脚本的开发,资源的协调等;
    6. 充分进行需求变更,通过改动点,精准圈定变更范围;


    2.2.5 冒烟测试阶段

    1. 严格按照约定的标准进行准入、准出;
    2. 根据过往合作情况,灵活调整冒烟策略;
    3. 对冒烟测试不通过的需求,进行记录;
    4. 可酌情,做必要的冒烟支持工作;


    2.2.6 持续改进

    质量数据积累

    通过积累的度量数据,提供分析,改进过程的数据依据。


    质量门禁建设

    质量门禁的作用,就是从需求阶段开始,尽早的介入需求设计、产品设计和技术方案设计等环节,通过评审、提问等方式,尽可能多的发现存在的问题,通过制定科学合理符合项目实际情况的准入准出标准,来保证每个环节流转到下一环节的输出结果,质量更高

    不但测试需要建设质量门禁,研发也同样需要。


    自动化测试用例库建设

    自动化测试用例建设是软件测试过程中的一个重要环节,帮助测试团队提高测试效率、减少人工测试的工作量,以及确保软件质量。测试人员,在项目结束后,要完善响应的case,通过自动化case的不断积累,来打破时间约束带来的问题。


    复盘总结+分享

    以史明鉴是一种重要的学习方法,定期复盘总结很有必要,能够帮助我们避免犯重复的错误,在错误中吸取教训,补充缺失点,并形成文档或报告,以供以后的项目参考。



    文章数
    1
    阅读量
    88

    作者其他文章