你会提交Bug么？

问：你会提交bug么？

答：测试人员必备技能，必然会。

如上对话的起因是这样的，近日提交bug后 ，开发在jira上备注，你提交的问题什么意思？

当看到什么意思时，有一种被质问的感觉，讲真，很不爽，说解决方法之前简单介绍下实际提交的 bug。

其实提交的 bug只写了标题（一句话描述了问题以及现象，个人认为这样就够了）外加一个附件。（现在来看个人自己给自己挖的坑）

解决方法：

开发看不懂，那就演示给开发看，优先保证开发解决问题。

其次在jira上把问题现象以及操作步骤补充完整，涉及到附件在描述中提及

反思：为何提交的 bug会被质疑？逻辑不清晰？描述不清楚？

问：对测试业务是否清楚？

答：内容不清楚时，找原始材料（需求文档、测试文档），问对应模块产品、开发、测试负责人

问：对测试端是否熟悉？

答：不熟悉时向对应端的测试专家请教

问：对涉及到的辅助测试系统是否熟悉？

答：找相关人员咨询（测试负责人、负责开发此系统的开发者、产品）

问：提交的 bug是否用开发看的懂的术语描述？

答：尽量使用术语，当不知如何描述时问开发、测试同事、Google获取对应的术语

问：提交的bug是否按照所在组内的bug格式提交？

答：一定要用组内的格式，入乡随俗

问：合作的开发是否喜欢看附件？

答：不是每个开发都看附件的，要在描述中进行提示

其实根本原因在于最近被安排测试app侧的内容，然初次下手测，前两天晕晕乎乎，部分术语与pc端不一致，还涉及到H5、native等，顺了两天才找到节奏，然通过提交bug这事，有些时候还是不能想当然。

最后说下，提交bug的关键字段：

1、测试环境（一定要说清楚，尤其有多套测试环境的时候）

2、是否需要登录（需要登录一定要提供用户名、密码）

3、操作步骤，一句话描述一个动作

4、预期结果，涉及到附件要说明

5、实际结果，涉及到附件要说明

友情提示：

附件中最好有，例如 log日志，关键操作步骤截图，数据库截图，配置项截图，根据bug所需提供即可。截图在回归时要比看文字更快速，毕竟自己提交的bug，问题原因已知晓。

提交bug的质量好与坏，也侧面反映一名测试的能力，个人认为开发对测试的态度与提交的 bug质量有关，如果你提交的 bug质量不高，需要二次沟通，开发没意见那是不可能的，所以不要小瞧提交bug这事。