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

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）如何改进基于风险测试的过程，提取预估到这样的产品风险?

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

6.Kano模型