如何简单高效地提有价值缺陷？

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）

Copy
（What）这个问题是什么?有什么影响?
（Why）为什么会出现这个问题?什么场景下会出现这个问题?
（Where）这个问题是在哪个阶段发现的?
（Which）缺陷是在哪个阶段引入的?
（Why）为什么会在这个阶段引入问题?
（hoW）如何避免引入这个问题?
（Where）应该在哪个阶段发现这个问题?
（Why）为什么没有在这个阶段发现这个问题?
（hoW）如何才能在这个阶段发现这个问题?
（hoW）如何改进基于风险测试的过程，提取预估到这样的产品风险?

5. 缺陷基于价值评估模型

6.Kano 模型