第七章：基于敏捷模式S公司质量搭建的第一阶段
目录
方案内容：
一、方案提起：
一）结合现有流程思考：质量形成主要分析以下三个方面：
二）测试左移测试左移本质上是借助工具和测试手段更早地发现问题和预防问题：
二、落地内容：
一）测试任务跟踪：
二）建立代码分支管理规范：
三）持续测试：
四）规范测试流程：
三、测试工作左移步骤
一）缺陷管理（生产）流程依据如图进行：
二）数据修改后记录管理：（举例）
三）测试流程规范性落实：
四）【测试任务】规范
五）加强上线前标准评估与总结复评：（内容如下图）
六）测试部门内部能力提升
七）质量管控搭建逐步强化
八）环境运用收口：
九）测试人员关注问题的思维强化：（举例）
基于敏捷模式下S公司质量搭建的第一阶段内容：
敏捷管理下进行规范性测试工作流程搭建，进行测试工作左移的具体方案计划
方案内容：
一、方案提起：
现公司测试流程已不满足工作的需要，结合公司的规划方向进行测试工作规范调整，调整工作采用敏捷结合CMMI模式进行，在管理中敏捷在工作过程中实施CMMI模式过程域控制理念：
一）结合现有流程思考：质量形成主要分析以下三个方面：
- 在产品质量设计管理
- 测试规范流程搭建与改进
- 质量控制与实施落地
在第一阶段进行中，主要对测试规范流程搭建与改进、质量控制与实施落地中进行，并以此完成测试工作左移的效果
二）测试左移测试左移本质上是借助工具和测试手段更早地发现问题和预防问题：
- 需求：对需求、架构和设计模型的测试；
- 开发：着重增加对单元、组件和服务层的测试；
- 持续测试：自动化测试。
二、落地内容：
一）测试任务跟踪：
不仅仅只是跟踪测试本身的工作，还需要介入到需求、技术方案、编码的全过程。只有前序每一步都跟踪到位，才能尽量避免测试过程中的不可控因素，从而保证产品质量做到“让数据为质量说话”
二）建立代码分支管理规范：
研发在编码过程中，需求多、分支多是常态，怎样让开发测试有序地协同工作，规范分支管理流程是必要的。
三）持续测试：
测试组内能力提升，逐步搭建接口自动化测试提升测试效率。
四）规范测试流程：
在测试流程中严格落实，通过规范的流程传导促进有效高效的内部协调。
三、测试工作左移步骤
一）缺陷管理（生产）流程依据如图进行：
缺陷提起时，提起人需严格落实两个方面内容填写：
- 1、现在实现；2、步骤描述；3、预期结果；
- 版本内缺陷无需研发人员编写原因及结果；若测试人员无法定位到预期实现的效果，需在评论中指定研发人员进行修改后实现描述。
- 投产环境缺陷进行优先验证，验证过程中相关人员进行详细问题描述（现在实现、步骤描述、预期结果），修改完成后将问题原因，修改后实现情况进行补充记录。
- 测试人员首先进行验证此缺陷产生的功能是否正常，若正常则进行数据检查（与研发人员及时沟通检查），此问题的解决方式是否是系统依据实现的，一次判断是否转需求，若需数据处理进行 2）数据修改后记录管理流程。
- 修改完毕后及时与投产业务负责人进行沟通说明
二）数据修改后记录管理：（举例）
|
Plain Text 修改内容：资产金额由4位小数改为2位小数 《执行语句见飞书文档》 *如需测试人员验证需进行编写在哪个资源验证哪个功能或那种业务那一步 *若无需测试人员验证研发自行记录 验证内容：生产环境在白天操作业务后，进行计划清单、总账核对，测试环境采用相同数据进行折旧模拟（资源名称+具体页面内容） 验证结果：修正后数据正确，通过抓包只有2位小数，折旧业务无影响 |
若需要测试人员进行修改后数据检查，采取以下两种方式：
- 检查生产环境数据是否按要求正确修改完毕
- 在本地环境同步修改数据后进行业务检查
三）测试流程规范性落实：
- 研发人员完成编码后，产品经理在测试环境进行主流程走查复核，复核通过交付测试人员进行测试；如测试人员主流程为执行通过即可进行版本打回处理，再次进行上述流程。
- 测试人员测试流程目前进行冒烟测试与集成测试，测试中落实测试用例执行记录，测试用例评审制度将采取组内评审与线下同行评审方式，采用短时间快速讲解，主要评审测试用例覆盖广度与深度，测试用例将更多的细化你想用例（需产品给出足够细的正向）
四）【测试任务】规范
- 测试任务在进行需求宣讲时进行编写，无需细致，主要进行记录跟踪测试执行情况
- 测试任务需在完全确定本版本故事下建立，初始化的开始时间结束时间与用户故事时间一致；测试任务最终开始时间为交付测试人员且测试人员进行提测时间，最终结束时间为故事测试完成时间
- 测试任务状态：建立完毕后【关闭】，产品复核通过后交付测试人员时【进行中】，完成该任务测试工作时【已完成】
- 临时任务添加后，测试任务需及时建立，但不进行时间选择，状态为【关闭】，测试计划不进行调整，主要以版本内测试任务计划进行，若优先级很高的，需及时沟通
- 测试任务建立后，需与“测试计划执行总结”故事进行关联，且在提测执行后，每天在测试任务评论进行进度记录
五）加强上线前标准评估与总结复评：（内容如下图）
- 上线前评估着重内容：可上线的任务、遗留的问题、风险产生的原因、解决的方式与时间
- 复盘总结：从工作流程上的点对点进行细化完善
六）测试部门内部能力提升
- 测试部门进行内部学习提升，逐步对信息传输、数据库、接口、性能进行学习提升
- 强化技术性场景、业务场景测试点提炼，结合功能测试，搭建接口、性能自动化框架，增加测试手段提高软件质量信心
七）质量管控搭建逐步强化
- 测试部门采取敏捷CMMI相结合方式，强化过程域的衔接质量管控
- 推动任务计划落地，强化沟通有效，达到内容快速落地，沟通须有数据有依据进行
- 结合过程需阶段性调整，调整后加以记录完善
八）环境运用收口：
- 版本确定研发任务编码完成后，在测试环境进行产品复核，复核通过后交付测试人员全量测试
- 测试人员完成版本内容后，此版本代码同步生产，在上线前评估时，优先提出是否需要资源配置、权限配置、黑白名单或数据处理
- 版本过程中增加的临时任务（不紧急），在研发人员编码完成后不同步代码，搭建分支管理
- 版本过程中增加的临时任务（紧急），在研发人员编码完成后同步到本地环境，本地环境与投产环境保持一致，进行线上环境缺陷验证/临时任务验证使用
- 版本过程中增加的补充任务（覆盖广/不确定范围），需进行测试任务重新规划，根据优先级、关联任务进行测试任务调整，将优先级、重要程度较低的排至最后（允许下版本迭代发布）
- 测试任务完成后，再次出现补充任务时，不进行排序，在完成已确定的测试任务后如有时间进行测试，如无时间则进行下版本迭代调整
九）测试人员关注问题的思维强化：（举例）
- 辨别问题
发生了什么？例如，在生产问题逃逸数的 C 图中发现一个异常控制点。
- 澄清问题
问题是什么？从抽象的数据表中剥离出异常点对应的相关数据，然后将数据反推定位到具体问题描述。比如，该问题描述是：“在版本 FP2.0 中，用户在发布环境上发现了已注册用户在输入正确的用户名和密码的情况下，依旧无法登陆 APP。”
- 分解问题
将问题分解成几个小单元。问题一：“所有已注册用户不能登陆吗？”回答一：“不是，只有用微信注册的用户无法登陆。”问题二：“未注册的用户能保证一定不能登陆吗？”回答二：“是的。”通过问题分解，可以缩小问题范围，确定生产问题是：只通过微信注册且没有通过 APP 注册的用户无法登陆。
- 用 5 个“为什么”来追根求源
“为什么这个问题会发生?”
“因为测试时没有考虑到只用微信注册的用户登陆的情况。”
“为什么没有考虑到这种情况？”
“因为测试用例没有覆盖这种场景。”
“为什么没有覆盖到这种场景？”
“因为没有做好需求分析。”
“为什么没有做好需求分析？”
“因为测试时间紧且需求范围过广颗粒度不够细。”
“为什么觉得测试时间紧？”
“因为整体版本所需要全量测试的不确定因素过多。”