今天的讨论非常有趣，希望大家能够从这一堆散乱的聊天记录中找到一些隐藏着的东西。如果有人在此留言写读后感，那我非常称赞你的归纳能力和思考能力。哥（姐）们，你太适合做测试这工作了。
开发A（开发A） 17：30：23
根据测试组提交的Bug单质量、对需求的理解和存在的一些问题，存在一些影响开发人员的时间和项目进度的问题：
1、Bug单提交问题经常出现描述随意，问题描述与实际偏差过大，操作步骤不能重现的问题，测试组其他成员和开发同样无法重现问题，应该附加截图和附件的没有附加
2、Bug单类型应该为建议的提交为缺陷和问题描述用词不准确
3、对测试方向，测试侧重点，Bug单重要性心里没有概念，关注Bug单数量而非质量
4、测试方法不专业使得多次提交不是缺陷的Bug单，简单问题仍需要开发指示测试方法
5、对需求了解不够，导致不能测试到系统重要分支和提交与需求不一致的Bug单，影响工作效率
6、测试工作不够细致和全面，问题存在的模块，可能引发问题的操作仅描述一个，剩下的问题交由开发去寻找
测试在软件生命周期中是占据重要环节的，建议文青山分享如何描述Bug单、提供有用的操作步骤经验，测试老大助理分享软件测试方法的经验，测试组内部多交流经验，适当组织培训，使得测试组能够发挥更高的工作效益。
开发老大（开发老大） 17：33：14
开发A的意见提的很重要，请测试组同事进行安排下，就如何提高测试工作效率展开讨论分析解决，烦请测试老大安排跟进下
测试A（测试A） 17：34：21
1、对于重现步骤中需要注意的细节的问题，测试会不惜笔墨详细描述，这是为了让开发能一次性最大概率地重现问题，最终目的是为了节约开发时间。至于bug详细描述的【问题提议】这部分内容，是测试对当前bug的一个分析，同样一个目的也是为了帮助开发更好地更快去分析bug引发的渊源，去更准确地定位bug的根源。若开发不需要测试分析，也可以避开不看该部分内容，完全不影响开发去理解去分析bug，请明晰。对于需要截图的bug，测试从未吝啬ctrl+shift+x
2、对于是缺陷，或是建议，缺陷有分功能缺陷与业务逻辑缺陷，并非非功能缺陷就不是缺陷，请明晰。对于某些问题是缺陷还是建议，没有一个明确的界定，更加开发与测试的思考问题的方式不同，理解也不同，因此同样，勿以开发的思维来强加于测试的思维。
3、提交不是缺陷的bug单，是曾经发生过，有些的确是测试对于一些细节不够严谨，有些属于其他系统数据变更或者重现概率较低的问题，没有开发说的那么严重。
4、请列明没有测试到的系统重要分支的问题，之所以提交与需求不一致的bug单，是因为测试在测试过程中发现用户在提出需求时可能没有考虑到的一些细节问题，这些都属于
测试A（测试A） 17：34：21
测试过程中不可避免的，也是测试的一个不可或缺的部分，发现该类问题并提出来，是测试的职责。
测试老大（测试老大） 17：43：01
有好的经验我们已经在内部计划开展培训。
开发A（开发A） 17：44：59
希望测试组能够把工作做到位，或是优秀，不能让开发也把这工作做了，因为做他人的工作是不礼貌的
开发老大（开发老大） 17：45：00
建议找个时间开个头脑风暴会议
议题如：如何有效率的提交有效的bug。大家可以选择
就该问题大家可自由展开讨论以及之前问题的总结等
测试老大（测试老大） 17：45：03
只不过最近一段时间比较忙，所以会放在之后进行。还有一个时：不能把所有的问题以开发立场来判断的方法。不过是问题的各自测试人员先反思可以从哪里提高。
