问：你会提交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这事。
