一、序
日常研测工作演绎
你是否也有同样的困惑？
跟进的需求，就在提测前一秒，被告知不能如期提测了，研测计划被打乱；
提测的功能，犹如遇到不好的购物体验，缺斤短两，与prd预期不符；
产研测三方需求理解不一致，临时组会讨论，出临时解决方案；
等等。。。
你是否也遇到了以下的挑战？
1.时间约束：敏捷开发周期较短，迭代速度快，使得测试人员很难在可用的时间内彻底测试软件；
2.回归测试：在不断地迭代中，系统功能大大小小的功能点，多如牛毛，如何能准确确定回归范围？
3.测试自动化：敏捷开发通常需要高度的测试自动化来跟上快速的开发节奏，测试case的开发和维护，都需要投入大量的时间和精力。
面对这些困惑、挑战，我们该如何去推动、提升研发的提测质量呢？有没有前置的动作，能够提高提测质量呢？
二、提测质量研测共建
软件项目中，影响产品质量的因素很多：需求质量、设计质量、编码质量**、**测试质量，甚至发布时的配置，都会影响最终的交付质量。提测前的工作占比高，为核心环节，过程、质量的好坏，直接决定最终的结果。
1. 责任与使命
参与者的参与度、责任感，都会直接影响整个产品质量：
目标管理："心之所向，行之所往，未来可期"，在软件项目中，也同样适用，有明确的目标，即把工作做好、做极致、做完美，才会有好的结果。
越位思考，本位做事：每个参与除了要考虑岗位职责范围的工作，还要将自己置身于整个过程、整个链路中，思考上、下游衔接点，做好无缝衔接。
拥抱变化：软件研发管理中，变化是常态，参与者要善于调整计划，适应变化。
自我提升：在工作中，不断地提升自身的技术能力，拓展业务知识，提高沟通和协作能力，通过持续的提升，提高工作效率，提升工作质量。
2. 项目管理
2.1 资源管理
人员是最为重要的项目资源，进行工作安排时，应充分考虑以下几点：
人员的责任心够么？能够支撑他完成这项任务么？
人员能力与项目所需能力是否匹配，会小马拉大车么？
人员对业务是否了解？是否能把握当前需求么？
人员的工作量是否已饱和？是否能消化当前需求？
2.2 流程管理
在每个迭代实施过程中，形成标准化的协作流，如下图：
在践行标准的流程下，还有些细节点可以帮助提升提测质量：
2.2.1 需求评审阶段
在敏捷管理中，需求评审是一个关键环节。需求是项目实施过程中共同的标准参考，需求的质量很大程度上决定了最终的交付质量，研测要在评审前，做充分的思考：
-
评审前，研测人员对需求进行预习，准备待确认问题，对需求问题进行信息拉齐；
-
抽象：从宏观层面，了解业务背景，理解要解决的业务痛点；
-
具象：了解需求功能，了解相关功能的上下文；
-
抽离：对功能进行推理、演化、扩展，提出需求未明确的场景，进行补充确认；
-
控场：对于歧义较大、需求缺失信息较多的情况，合理拒绝。
-
对评审的问题，形成待办，落实责任人。对问题进行跟进，对结论进行同步。
2.2.2 研发设计评审阶段
在敏捷管理中，设计方案评审是一个重要的环节，旨在确保项目的设计方案符合项目需求、技术标准，准确评估影响范围。
-
研发人员需要编写清晰、具体、可验证的设计文档，数据库设计，接口文档，以便在评审过程中更好地理解和评估设计方案；
-
测试人员评审前对相关文档进行预习：包含但不限于以下文档，设计文档、依赖的内部、第三方、企微接口文档、数仓表、上下游功能等；
-
测试人员准备待确认问题，不限于设计问题，也可包含业务场景补充、影响范围补充；
-
测试人员提合理的物料要求：比如造数、日志关键字支持，在测试环境进行冒烟测试，配置依赖的配置信息，通过业务流完成冒烟测试；
-
测试人员，可以提前识别复杂造数场景，与研发沟通，协商采用脚本或其他工具提前完成；
-
研发技改需求，研发为了追求完美，方案可能会改多版，改动随意，要求明确改动点，影响范围，回归范围；
2.2.3 研发开发、自测阶段
-
频繁沟通，保持频繁、及时、有效的沟通，确认需求理解一致性，确保对项目的需求和进展有清晰的理解；
-
对业务背景及需求理解透彻，避免开发方向性错误；
-
合理设计方案，具备灵活扩展、足以应对小的需求变更的能力；
-
合理工作拆分，尽量减少交叉工作及相互依赖；
-
合理评估工作量，细化工作内容，规避工期对质量的影响；
-
合理设计自测场景，提前了解测试用例，提高自测意识及覆盖度；
-
全面评估及约束影响范围，避免对已有功能产生不可预知的影响；
-
开发细节过程可追溯，避免在测试阶段遗漏；
-
代码评审，通过评审，帮助团队发现签潜在的问题，提高提测质量。
2.2.4 测试用例设计及评审阶段
-
测试用例前置，帮助团队发现潜在的问题，避免在后期才发现问题，从而降低修复问题的成本；
-
充分理解需求，了解业务的痛点，从业务层设计，全面覆盖业务场景；
-
理解技术实现过程，了解数据存储及数据处理逻辑，多考虑可能的异常情况，对数据的不同态进行考虑设计；
-
自动化测试用例资源盘点，复用自动化用例，提高测试效率，扩大测试回归范围，保证测试质量；
-
测试物料准备工作前置，环境的构建，数据的准备，脚本的开发，资源的协调等；
-
充分进行需求变更，通过改动点，精准圈定变更范围；
2.2.5 冒烟测试阶段
-
严格按照约定的标准进行准入、准出；
-
根据过往合作情况，灵活调整冒烟策略；
-
对冒烟测试不通过的需求，进行记录；
-
可酌情，做必要的冒烟支持工作；
2.2.6 持续改进
质量数据积累
通过积累的度量数据，提供分析，改进过程的数据依据。
质量门禁建设
质量门禁的作用，就是从需求阶段开始，尽早的介入需求设计、产品设计和技术方案设计等环节，通过评审、提问等方式，尽可能多的发现存在的问题，通过制定科学合理符合项目实际情况的准入准出标准，来保证每个环节流转到下一环节的输出结果，质量更高。
不但测试需要建设质量门禁，研发也同样需要。
自动化测试用例库建设
自动化测试用例建设是软件测试过程中的一个重要环节，帮助测试团队提高测试效率、减少人工测试的工作量，以及确保软件质量。测试人员，在项目结束后，要完善响应的case，通过自动化case的不断积累，来打破时间约束带来的问题。
复盘总结+分享
以史明鉴是一种重要的学习方法，定期复盘总结很有必要，能够帮助我们避免犯重复的错误，在错误中吸取教训，补充缺失点，并形成文档或报告，以供以后的项目参考。
作者：京东零售 王兰青
来源：京东云开发者社区 转载请注明来源