一、序

日常研测工作演绎

你是否也有同样的困惑?

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

提测的功能,犹如遇到不好的购物体验,缺斤短两,与 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 的不断积累,来打破时间约束带来的问题。

复盘总结 + 分享

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

作者:京东零售 王兰青

来源:京东云开发者社区 转载请注明来源


↙↙↙阅读原文可查看相关链接,并与作者交流