???????3.4號小組進行了第二次討論，這次討論的主題是如何和開發人員溝通，說明他們修改問題。開發和測試在項目是即統一又對立的：統一的是對項目的愿景，都希望項目質量合格，最好是優秀；對立是因為測試是在‘‘找茬’’，找開發的茬。所以在溝通上是非常重要的，畢竟大家的目標是一致的。
???????主持細雨紛飛提出了他的看法是：1?堅持原則，是問題就要修改 2問題要表達清楚明確有截圖和日志 3 和開發維持良好的關系，建議友誼，拉近關系。
????????首先前兩點是測試在提bug時需要做到的最基本的。第三點是中國的特色了，關系好自然什么都好講話。實際在工作中，真的是功能上的問題，代碼有問題我想開發都不會否認的，更多需要去溝通交涉的是用戶體驗，譬如易用性，用戶習慣類的問題，這些看上去是處于可改可不改的范疇。關于用戶體驗這塊，最主要的是看業界主流產品是怎么做的，基本都會跟主流產品保持一致。而且溝通的過程最主要是要控制情緒，我記得以前看過介紹溝通的文章里寫到，溝通80%溝通的是情緒，20%才是內容，所有雙方都必須是客觀冷靜的，尤其言語間不要帶到對他人品質行為的點評。
???????其實前期的工作做的比較好，后期需要溝通的就會減少，譬如小河在討論開始提到的一個問題，就是開發任務測試測得問題太晚了，這種問題怎么解決溝通。首先我個人覺得測出問題早晚看是否首輪測出，如果是首輪測出就不算晚，如果不是，那就是內部泄露，那測試就要做出相應的措施，找出首輪未發現的原因，并制定相應的解決方法。細雨對這個問題的看法是：1對需求理解不透徹，深層次的業務邏輯沒有吃透 2?測試用例評審流于形式，評審不夠細致 3測試人員效力不夠。對于前兩點其實還是比較好解決的，首先當有新需求來了之后，相關測試人員需要自我解讀需求，然后需求人員能組織需求解讀會，測試可以在會上將不明白的點提出讓相關人員解釋。在需求了解清楚后開始寫測試用例，用例寫完后不能只在測試組內部評審，也要給SE和相關開發人員評審，這樣就可以避免開發和測試對需求理解有偏差找出的bug溝通，也可以避免開發職責測試用例寫的不夠完整準確。
????????小巖還提出另一個問題是，測試發現問題跟開發溝通，開發會說這個問題他們已經發現，跟同事溝通，說沒有解決辦法。我們一致任務不管有沒有辦法解決，是問題就要提bug，首先這保證了測試的工作到位，以防現場報錯后說是測試泄露，第二方便問題跟蹤，給后面做項目評估給出相關依據。
???????當然當測試跟開發實在談不攏，沒有定論的時候就只能讓上一級來做決策，這不存在什么打小報告的問題，實際求是就可。
???????討論最后還提出了跟上級溝通的問題，總結的點就是積極匯報工作進展，測試遇到問題及時上報，給老大留下積極主動的好印象。報告當然也要寫的漂亮。還有要了解上級的關注點，洋洋灑灑寫了篇巨作，領導沒看到他想看的也是沒用的。
???????溝通是個不斷摸索改善的過程，是工作中非常重要的技能，希望我們都能做個溝通小能手
