产品设计质量管理
产品设计是研发的核心主导，因此，高效高质量的研发离不开清晰合理的产品设计。因此，有必要对产品设计质量提出明确的要求，从而更好的指导研发团队保质保量的完成研发工作任务。
产品设计交付资料
产品设计交付资料至少要包含产品原型，同时附加必要的备注和说明。原型中的页面跳转关联逻辑要准确无误，备注要指明输入限制，异常情况及其他可能出现的负向操作；说明中要阐述明白产品功能的背景，作用及实现流程。对于复杂的产品逻辑，还应给出其他辅助性的说明，如流程图，思维导图，产品架构图，数据流转图等。帮助研发准确的理解产品。另外，对外产品还应附加UI蓝湖文件。
产品设计交付方式
产品设计交付通过评审的形式交付，一般由产品经理组织相关研发和测试参与需求评审，评审时间不得晚于研发计划制定时间。核心功能可由产品负责人，各相关研发组负责人进行首轮评审。首轮评审通过后再组织相关研发和测试参与需求评审。对于需求评审提出的合理修改建议，如果要纳入当前版本完成的，产品应在三个工作日内完成修改，并书面（邮件，工作群或原型说明）通知相关研发及测试，知会相关负责人。产品或项目首次设计及其他重点页面设计，由UI组织相关产品，研发，测试及负责人参加评审。月迭代UI交付日期不得晚于产品交付日期5个工作日。
产品设计质量评估
鉴于目前实际情况，产品质量暂时无法通过市场调研等形式评估。因此，产品在遵循上述规定的前提下，只增加产品逻辑变更情况评估。产品设计完成后，由于产品设计逻辑原因引发的产品变更，导致研发及测试整体工期延误的，属于产品质量问题。产品逻辑变动而引起的额外研发测试工时达到总研发测试工时的5%时（工时评估由产品，研发和测试的共同负责人评定），可认定为产品设计存在缺陷；达到10%时，可认定为产品设计存在较大缺陷；达到15%时，可认定为产品设计存在严重缺陷；超过15%时，可认定本次产品设计不合格，需重新设计。由于产品设计不合格而引起的工期延误，由产品设计责任人承担。
开发质量管理
时间基线
移动端普通接口响应时间基线为1s，移动端普通交互事件响应时间基线为1.5s；移动端统计类接口响应时间基线为1.5s，移动端统计交互事件响应时间基线为2s；下载接口响应时间基线2s。
迭代测试
迭代测试是指按月上线的产品迭代测试。迭代测试应由研发主管或研发本人提测，提测应注明提测功能，可能影响的原有功能及测试重点建议。迭代测试原则上分为3个测试周期，第一个周期为冒烟测试，默认测试时间为2个工作。冒烟测试主要测试各个功能的主要流程是否能够走通，各个辅助功能是否齐全。如果主流程无法走通或主流程性能超出时间基线2倍以上或辅助功能超过整个功能10%时（如有必要，测试提交产品评估），测试应将提测打回；第二个周期为整个新功能的全面测试，默认测试时间为4个工作日。第三个测试为整个系统集成测试，测试应覆盖系统的所有主要流程，包括但不限于登录，注册，注销，下载，更新及其他核心功能模块（如培训，IM主流程），默认测试时间为3个工作。特殊情况下，可根据需求的多少及难以程度调整测试时间，但需要在指定计划时特别指出，否则按默认测试时间计算。
Bug分类
严重Bug（Critical Bug，编号1）
定义：严重影响系统核心功能、导致系统崩溃或用户无法正常使用的Bug。如系统无法启动或频繁崩溃，关键功能模块无法正常使用，界面卡死或严重卡顿，影响正常操作等。
普通Bug（Major Bug，编号2）
定义：必须修改的Bug，对系统功能有较大影响，但不会导致系统崩溃或主要功能无法使用。普通bug是研发自测容易忽视或自测成本较高的bug，如边界值测试，负向测试，兼容性测试，压力测试，并发测试得出的bug。
轻微Bug（Minor Bug，编号3）
定义：建议性Bug，经产品确认可以不修改的Bug，对用户体验有轻微影响，但不影响主要功能使用。如内部管理系统页面布局轻微错位或美观度欠佳，提示语正确但不够精简，加载速度满足时间基线但仍有卡顿等。
低级Bug（Low-Level Bug，编号4）
定义：研发功能自测完全应该可以避免的，或者违背常识性的Bug，Bug引起的主要原因是没有自测。
低级bug举例：
- 未自测而引起的低级bug，如：辅助性功能页面无法加载，操作按钮无法显示或按钮事件没有绑定，接口报404错误等。衡量标准是：只要测试该功能，不论任何参数输入，都一定会出现bug，且该bug的表现形式显而易见，在严重程度上达到了普通级别。
- 违背常识性的低级bug，如：日志列表（几百，几千甚至几万条数据一次加载）没有分页；输入框没有基本校验（纯数字输入框里可以输入汉字，必填项为空时可以提交等）。衡量标准是：违背业内统一认识，主要是由于实现者缺乏责任心，代码太随意而造成的。例如输入不校验的根本原因在于认为“不重要”或“时间紧”，而非“没想到”。因此，我们要遏制这样的bug数量，提高研发团队的整体代码质量。
- 违反编码规范而引起的bug，如：非空字段返回值实际内容与接口描述不一致而导致的null，可以为空的字段未经校验直接显示而导致的undefind等。
Bug处理
bug可以由参与项目的所有成员提出，但必须回归到测试。bug提出后，研发应在1个工作日内确认bug，两个工作日内回归bug。否则记录为超时bug。如果因技术原因而一时无法解决的bug，需要及时提交给研发主管。研发主管应在两个工作日内会同产品及测试决定bug处理方式，包括继续处理，延期处理，转需求和不予解决。对于继续处理的bug和延期处理的bug，应给出处理期限，并留存在研发主管处，有研发主管完成或督促完成，完成后由研发主管回归到测试；对于转需求的bug指定到产品经理，由产品经理整理到需求并完成需求讲解后回归给测试；对于不予解决的bug，应指定到产品，然后由产品回归到测试。
bug一旦回归且解决方案为“已解决”时，意味着测试环境已无此bug，测试可以随时复测。回归的bug复测问题仍然存在，且该bug为必现bug时，测试应将该bug应标记为重现bug，并指向研发主管，由研发主管完成或督促完成后回归测试。
测试报告
测试报告缺陷分析中除了各级bug数量和比例之外，增肌低级bug，超时bug的个数及比例。如果研发个人低级bug占比达到20%或单个月份迭代超过10个时，应在测试报告中备注；重现bug和超时bug占比达到5%或单个迭代达到3个时，应在测试报告中备注。
测试报告主送前后端负责人，研发负责人，运营负责人及产品负责人；抄送相关研发，产品（含UI），测试及运营。