产品
产品内部需要先进行需求评审，确定需求后，才能跟技术进行需求宣讲；
需求宣讲前，至少提前1天把需要宣讲的需求发出来，通知测试和开发宣讲时间和地点；
需求宣讲后，测试和开发有疑问，产品需进行Q&A，维护到对应需求文档上，并及时更新需求；
需求宣讲完成，原则上不允许进行需求变动；如果进行需求变动，需要在协作平台提需求变更，开发和测试重新评估时间；
产品新增/变更需求，需要进行三方周知，不能只单方通知到测试或单方只通知开发；
产品规划需求前，涉及多方业务时，需要跟多方业务部门沟通清楚，避免出现上线后临时又要优化需求的现象；
开发
开发在需求宣讲后，需要理解并拆分需求，及时跟产品沟通并督促 产品更新需求；
开发前期需求需要完全了解，非自己开发部分也需要大概了解；
开发完成后需要重新核对一遍需求，有些需求变更才不会漏掉；
开发需要测试部署时，要提供完整的部署信息（包括：环境、服务、分支）和部署说明（本次部署的目的）；
开发在设计评审阶段，可以让测试一起参加了解；
开发不允许私自修改或优化代码但没有告知测试，很容易导致测试漏测；
开发bug原则上需要日清，紧急和严重问题非特殊情况必须日清；
开发提测前，需要将全流程都跑通（执行冒烟测试用例）才能提交测试，不能只是每个开发模块开发完成，独自模块自测完成后就算提测；
涉及到迭代开发的所有人员都需要清楚每个迭代的节点时间（提测时间、预生产时间、上线时间）；
开发身上的bug，如果需要流转到其他开发，需要备注下一个开发需要帮忙做的事情，然后私下再通知对应开发帮忙排查问题；
开发解决bug后，需要备注出现问题的原因和影响范围，方便测试回归验证；
开发提测，需要有提测说明和影响范围说明（开发全功能提测后，发现有不影响主流程的问题，正在修复，也可以写到提测说明中）；
开发不能私下接需求，产品新增或修改需求，需要测试也评估后才能决定是否新增/修改；
开发提测后，可以多对自己的代码和本次迭代流程进行测试，在测试发现问题前先消灭掉（建议）；
最好是能前紧后松，不要所有东西都堆积到后面来处理，导致后面发布风险；
开发过程中碰到有2个小时内自己都解决不了的问题，要向上寻求帮助，不要耗上一天或者半天的时间；
群里或者私聊的时候，有看到消息开始处理了要通知一声让对方了解情况，所有消息都最好能稍微回复/反馈；
测试提测问题单，如有描述多个问题场景，要所有场景都处理才算修复，修改好的问题自己要先核对正确了再提测，不要反复浪费时间；
上预生产，上生产，负责人要提前做好脚本和配置的工作，同时要核对下预生产和生产是否跟测试环境有差别，提前规避因为此类问题导致上预生产/生产的时候才发现问题，耗费时间；
问题修复及时更新状态给测试，所有问题到测试手中都必须是已解决的，同时要区分延期，不处理，已处理。已处理代表是有修改内容，不处理和延期必须要跟测试和产品沟通确定ok才能改成这类状态，非缺陷的请备注好原因通知测试重新验证；
多版本同时在测试环境的时候，要注意不要版本之间混杂在一起；
多个需求在同个版本上线，各负责人合并代码，上线等各个节点需要互相通知，保证最后合并后的分支包含各部分内容，同时同一个版本打tag前最好使用相同分支号，这样打包部署才不会混乱；
开发提交上线单子（线上变更）标题规范：标题：【上线任务】系统+版本+上线内容+上线时间
如：【上线任务】财务中台-结算中心V1.6.1 大兴机场资金结算 上线 2019-11-01 22:30
测试
需求分析
.拆分需求，需要确认的问题，整理成文档发给产品确认，并督促产品维护Q&A到对应需求文档上，及时更新需求文档；
测试用例编写
.编写测试用例时，要100%覆盖到产品需求，覆盖完整后再补充场景、边界、异常等测试用例；
.编写测试用例，标注测试用例级别，1级用例为开发提测前必须自测通过的主流程case，提测后测试以此进行冒烟测试；
.测试用例编写完成后，至少要在测试用例评审的前1天把发出用例发到群里@开发负责人、测试负责人、对应开发和对应产品，通知大家用例评审的时间和地点；
.需求宣讲完成后，所有的需求变动和新增，都需要开发和测试一起评估，同意变更后，需让产品补充需求文档和提需求变更单子，不接受口头需求变更，不接受单方面需求变更
测试前
.提测前1天跟开发确认提测情况，确保提测日期当天可以顺利提测；
.提测后优先进行冒烟测试，冒烟测试结果发群里@开发负责人、测试负责人、对应开发和对应产品（PMO）；
.冒烟测试不通过，不算提测；冒烟测试通过，提测成功，测试进入测试阶段；
.冒烟测试模板规范：
冒烟测试模板
【系统+版本号】
【冒烟测试结果】冒烟通过/冒烟不通过
冒烟项1：冒烟结果（通过/不通过）
冒烟项2：冒烟结果（通过/不通过）
冒烟项3：冒烟结果（通过/不通过）
……
艾特开发、测试、产品负责人
（冒烟测试不通过的，需要写明不通过的原因/存在的bug）
测试中
.测试中，遇到阻塞问题，及时群里@对应开发和开发负责人，督促问题及时解决，不要私聊；
.测试中发现开发私自修改代码没有同步测试，群里周知，督促开发规范性；
.开发解决bug，要求开发需要备注修复原因和影响范围，方便测试验证回归；
.开发需要把bug解决后测试才能验证关闭，测试不能自己修改bug状态进行关闭操作；
.测试中提的bug，原则上需要日清，紧急和严重问题非特殊情况必须要求开发日清，测试及时验证开发日清的bug
.测试环境测试完成，计划上预生产，提前在群里@开发和开发负责人，安排准备上预生产的脚本和配置，不要私聊；
.预生产流程走通后@产品同步验收；
.预生产测试完成前，提前群里@开发和开发负责人打tag；
.tag验证没问题，上线当天群里@开发、开发负责人和产品 ，上线通知；
.及时更新协作平台上测试任务状态；
.多项目或多人配合时，环境部署（开始部署和部署完成）需要再群里通知；
.遇到任何不清楚，不明确，有疑问的都需要在群里跟产品/开发确认，涉及修改需求时督促产品更新需求；
.测试中发现的问题，都要提交协作平台记录，不能只是口头传达；
.测试不能100%确定要延期的问题都需要跟产品确认，原则上需要延期的问题都要跟产品沟通；
测试完成
.上线完成，@产品已经上线完成；
.jira上线单子，上线完成后，需要@2个群组（@tech_pm和@tech_leader），备注测试情况，并把jira单子指派给对应开发；
.协作平台上线单子，上线完成后，备注测试情况，关闭上线任务；
线上操作
.上线后，本次上线的内容能验证的都需要验证，不能验证的群里通知产品，产品第二天需要配合业务部门进行相应功能验证；
上线后第二天跟踪
.上线后，第二需要关注并响应群里的消息和问题；
.上线较晚，第二天在家支持，也需要关注并响应群里的消息和问题；
