如何简单高效地提有价值缺陷？#
1. 什么情况应该提缺陷 (Issue)/ 问题 / Bug?#
1）功能同需求不符，或是技术问题
2）问题是自己或小组内不能解决，需跨部门沟通或支持
3）暴露出我们流程或管理问题
4）功能需求不符要提，功能有误要提，功能不符合大众口味要提。
2. 缺陷 Defect/Bug 六大要素#
1) 标题：#
简洁描述 bug，bug 在哪里发生？
发生了什么问题的概括，突出关键字的作用，保证无语法错误，很容易用关键字搜索，容易指派给下一个人。
2) 重现步骤：#
完整并简洁描述 bug 重现的每个步骤，
但不需要包括每一个小步骤，保证任何相关成员可以理解这个问题，
保证按描述能重现问题，如有前提条件，用一句话简洁介绍并相关测试数据。
3) 实际结果：#
描述看到的实际结果，不能用一张截图代替。
4) 预期结果：#
正确并且标准的结果，与实际结果相关联。
5) 环境信息：#
系统和浏览器（缺陷系统的提单可选），当还有别的环境信息需要补充时，请在预期结果的下方补充。
6) 附件：#
图片应该用明显的画笔标记出问题点，如有必要需要加上简要说明；
视频应该在尽量短的时间内操作完成整个问题重现的过程；
日志应该附上完整的相关日志，不要带上大量不相关日志。
3. 缺陷 Bug 提交注意点#
除了 bug 六大要素之外还需要注意以下几点
准确填写 “模块”、“所属项目”、“影响版本”、“类型 / 严重程度”、“系统 / 浏览器”；
“当前指派” 指给开发负责人（不清楚时请测试负责人协助）；
bug 标题中不需要填写子系统名称，因为产品模块中已经选择；
指派给对接人作第一次分析并 “抄送给” 上级；
编辑 bug 的优先级。希望 20% 缺陷是 1/2 级，bug 有个轻重缓急，可以优选解决大价值问题。
4. 缺陷调査 (10 个 Why）#
（What）这个问题是什么?有什么影响?
（Why）为什么会出现这个问题?什么场景下会出现这个问题?
（Where）这个问题是在哪个阶段发现的?
（Which）缺陷是在哪个阶段引入的?
（Why）为什么会在这个阶段引入问题?
（hoW）如何避免引入这个问题?
（Where）应该在哪个阶段发现这个问题?
（Why）为什么没有在这个阶段发现这个问题?
（hoW）如何才能在这个阶段发现这个问题?
（hoW）如何改进基于风险测试的过程，提取预估到这样的产品风险?