3.4号小组进行了第二次讨论，这次讨论的主题是如何和开发人员沟通，说明他们修改问题。开发和测试在项目是即统一又对立的：统一的是对项目的愿景，都希望项目质量合格，最好是优秀；对立是因为测试是在‘‘找茬’’，找开发的茬。所以在沟通上是非常重要的，毕竟大家的目标是一致的。
主持细雨纷飞提出了他的看法是：1 坚持原则，是问题就要修改 2问题要表达清楚明确有截图和日志 3 和开发维持良好的关系，建议友谊，拉近关系。
首先前两点是测试在提bug时需要做到的最基本的。第三点是中国的特色了，关系好自然什么都好讲话。实际在工作中，真的是功能上的问题，代码有问题我想开发都不会否认的，更多需要去沟通交涉的是用户体验，譬如易用性，用户习惯类的问题，这些看上去是处于可改可不改的范畴。关于用户体验这块，最主要的是看业界主流产品是怎么做的，基本都会跟主流产品保持一致。而且沟通的过程最主要是要控制情绪，我记得以前看过介绍沟通的文章里写到，沟通80%沟通的是情绪，20%才是内容，所有双方都必须是客观冷静的，尤其言语间不要带到对他人品质行为的点评。
其实前期的工作做的比较好，后期需要沟通的就会减少，譬如小河在讨论开始提到的一个问题，就是开发任务测试测得问题太晚了，这种问题怎么解决沟通。首先我个人觉得测出问题早晚看是否首轮测出，如果是首轮测出就不算晚，如果不是，那就是内部泄露，那测试就要做出相应的措施，找出首轮未发现的原因，并制定相应的解决方法。细雨对这个问题的看法是：1对需求理解不透彻，深层次的业务逻辑没有吃透 2 测试用例评审流于形式，评审不够细致 3测试人员效力不够。对于前两点其实还是比较好解决的，首先当有新需求来了之后，相关测试人员需要自我解读需求，然后需求人员能组织需求解读会，测试可以在会上将不明白的点提出让相关人员解释。在需求了解清楚后开始写测试用例，用例写完后不能只在测试组内部评审，也要给SE和相关开发人员评审，这样就可以避免开发和测试对需求理解有偏差找出的bug沟通，也可以避免开发职责测试用例写的不够完整准确。
小岩还提出另一个问题是，测试发现问题跟开发沟通，开发会说这个问题他们已经发现，跟同事沟通，说没有解决办法。我们一致任务不管有没有办法解决，是问题就要提bug，首先这保证了测试的工作到位，以防现场报错后说是测试泄露，第二方便问题跟踪，给后面做项目评估给出相关依据。
当然当测试跟开发实在谈不拢，没有定论的时候就只能让上一级来做决策，这不存在什么打小报告的问题，实际求是就可。
讨论最后还提出了跟上级沟通的问题，总结的点就是积极汇报工作进展，测试遇到问题及时上报，给老大留下积极主动的好印象。报告当然也要写的漂亮。还有要了解上级的关注点，洋洋洒洒写了篇巨作，领导没看到他想看的也是没用的。
沟通是个不断摸索改善的过程，是工作中非常重要的技能，希望我们都能做个沟通小能手
