质量保障规范

在项目中，比bug更可恶的是不规范的流程和不规范的操作。当然，也正是由于这些不规范，给项目埋下风险和问题。如何去规范团队的流程，也是测试同学需要思考的问题。

一、需求管理
1、需求分析时一定要通知相关的开发、产品，并且对于大的改动要知会上下游相关人员
2、需求评估时要产品确定业务价值和项目优先级
3、需求改动时一定要以邮件的方式发出，并要求产品及时在需求文档上做修改
4、对于一些无产品的小需求、小优化、重构，要求开发提前通知测试同学，并且一起讨论影响点后才可以开始进行coding

二、提测管理
1、任务要有任务单（如jira单），在敏捷面板中统一管理，任务由业务方负责人或项目leader提出
2、提测邮件包含jira单、改动点描述（不允许夹带未在本次提测包含的代码改动）、影响范围、git地址和分支、sql脚本等
3、提测前需要开发自测通过（测试同学需要先给出自测用例）

三、缺陷管理
1、项目缺陷地址：jira、禅道等
2、测试提交缺陷规范
1）缺陷主题
2）缺陷等级和优先级
3）缺陷模块
4）关联的jira任务
5）操作步骤（重现步骤，包括账号等方便开发排查问题）
6）问题描述
7）附件（截图或者视频）
3、开发解决问题后备注规范
1）问题原因
2）该问题影响点
3）解决方式
4）总结（如何避免这样的问题）

四、发布管理
1、测试通过后，发测试通过邮件，知会产品验收，产品验收后发验收通过邮件，相关人员准备上线事宜
2、不允许开发有直接上线的权限，不管是大改动还是小改动都要有任务单并且测试拖单后才允许上线
3、对sql脚本要在上线单或者邮件中附上，不允许开发直接把脚本通过聊天软件私下发给运维人员执行
4、上线前要考虑此次改动点是否需要知会上下游业务方（特别是公共服务类）
5、上线前项目相关人员要讨论上线策略，以及一上线时出现严重问题的回滚策略
6、上线后要有开发或者运维观察一段时间线上日志，并且至少需要一名开发及时跟进解决可能会出现的线上问题

五、故障管理
1、重要的业务功能有技术负责人、业务责任人、应用场景、延迟或错误带来的影响、是否会发生资产损失等记录，出现故障时可第一时间知会相关人员，以及方便根据故障等级管理故障
2、故障发生后，需要相关负责人快速地识别故障原因，并迅速解决，消除影响。在处理故障的过程中，尽快将故障的处理进度通知到相关方，尽可能减少对业务的影响
3、对于故障会进行Review，分析故障的原因、处理过程的复盘、形成后续解决的Action，并且都以文字的形式详细记录，避免同样的问题再次出现