結(jié)合互聯(lián)網(wǎng)企業(yè)，產(chǎn)品技術(shù)部的實踐，以下對話是QA同學(xué)工作過程中耳熟能詳?shù)膶υ?，下面處理方式看似詼諧搞笑，其實仔細想想都是奔著把問題解決的方向去溝通的，所謂的“情商”，“溝通表達能力”，處處體現(xiàn)在工作細節(jié)當(dāng)中。
1. 當(dāng)開發(fā)詳細詢問bug場景
- 錯誤做法
直接回復(fù)開發(fā)：“bug管理系統(tǒng)中寫得非常明確，自己回去仔細看。
正確做法
首先，詢問開發(fā)是否已經(jīng)查看bug管理系統(tǒng)的bug描述和復(fù)現(xiàn)步驟。
如果，開發(fā)沒有查看bug描述，告訴開發(fā)在bug系統(tǒng)中已經(jīng)詳細說明bug的復(fù)現(xiàn)步驟。如果再有不明確的地方，可以隨時溝通。
如果，開發(fā)已經(jīng)查看bug描述，還是有不清楚的地方，那么需要針對有疑問的地方進行詳細解釋，或者當(dāng)面溝通。
最后，需要反思自己提交的bug描述和bug復(fù)現(xiàn)步驟是否清晰明了。提交bug的時候，做到描述詳細，清晰明了。如果是UI方面的bug，可以附上截圖。自己附上造成bug 原因更好，有助于開發(fā)定位bug。
2. 當(dāng)開發(fā)自測不充分，產(chǎn)品有嚴重bug阻礙測試
- 錯誤做法
直接找開發(fā)leader反映，或者直接和開發(fā)吵架。
正確做法
在提測系統(tǒng)中，將本次提測打回，注明理由“冒煙測試未通過，出現(xiàn)嚴重bug，阻礙了測試進行”。
找開發(fā)溝通，告訴開發(fā)冒煙測試未通過。詳細告知嚴重bug復(fù)現(xiàn)步驟和發(fā)生原因。
并且告知開發(fā)，該bug嚴重影響到了測試工作開展，希望開發(fā)修改bug充分自測之后，再提測。
3. 當(dāng)開發(fā)實現(xiàn)的功能不符合產(chǎn)品需求
- 錯誤做法
按照開發(fā)的邏輯走，視而不見。
正確做法
首先自己對產(chǎn)品需求進行客觀分析，如果產(chǎn)品需求是合理并且經(jīng)過事先評審，那么提bug給開發(fā)，并且告知開發(fā)原因。
如果開發(fā)對產(chǎn)品需求有異議，并且執(zhí)意按照自己邏輯的開發(fā)，那么可以拉上產(chǎn)品一起，進行三方溝通，達成最終方案。
4. 當(dāng)開發(fā)偷偷改代碼，直接上線出現(xiàn)了bug，求助你時
- 錯誤做法
開發(fā)的鍋，自己背。
正確做法
首先，提醒開發(fā)進行版本回滾，盡量避免線上影響。
然后，和開發(fā)一起找bug，并且分析bug原因。
最后，回顧整個事件，告訴開發(fā)直接上線的風(fēng)險所在。并且推動上線流程體系完善，只有測試完成并且無修改之后才能上線。
5. 當(dāng)開發(fā)修復(fù)bug不積極，導(dǎo)致項目延期風(fēng)險，需要你陪著加班
- 錯誤做法
讓開發(fā)獨自加班，對項目延期視而不見。
正確做法
首先，還是明確告訴開發(fā)，他自身bug修復(fù)不及時，導(dǎo)致項目有延期風(fēng)險。
然后，從項目角度出發(fā)，陪同開發(fā)加班，對bug進行回歸測試和驗證，保證質(zhì)量的情況下，盡量不拖延項目。
6. 當(dāng)開發(fā)因為你的bug誤報，鄙視你的時候
- 錯誤做法
直接懟開發(fā)，居然懷疑自己的專業(yè)素養(yǎng)，大吵一架。
非得將黑的辯解成白的，堅決否認是bug誤報。
正確做法
首先，承認自己的工作失誤，然后給開發(fā)說抱歉自己誤報了。
并且請求開發(fā)一起幫忙查找真正的原因。
自己學(xué)會總結(jié)分析，bug誤報的原因。盡量避免再次誤報。
努力提升自己的專業(yè)素養(yǎng)，樹立自己的專業(yè)形象。
7. 當(dāng)開發(fā)因排期緊張，有些bug不修復(fù)，直接帶bug上線
- 錯誤做法
直接放任開發(fā)上線。
正確做法
需要對不修復(fù)的bug進行評估，如果是影響范圍極小，并且偶現(xiàn)性bug，可以考慮排期的情況下允許上線。
如果bug嚴重級別較高，并且影響范圍大，堅決要求開發(fā)進行bug修復(fù)。然后才能上線。
8. 測出一個bug時
- 錯誤回答
1、你這里有一個bug，快修吧
2、你這代碼寫得也太爛了
3、你又出bug了，怎么回事
正確回答
前提：先排除測試環(huán)境、未提測等相關(guān)問題；
回答：hi，***，BUG來襲請簽收。
9. 當(dāng)開發(fā)不能復(fù)現(xiàn)bug的時候
- 錯誤回答
1、我這可以啊
2、你操作步驟不對吧
3、你看看bug中我的操作步驟
4、這么簡單你都復(fù)現(xiàn)不了
正確回答
前提一、確認開發(fā)與我的當(dāng)前測試環(huán)境是同一版本
前提二、在bug描述的時候清楚的寫明bug復(fù)現(xiàn)的步驟與輸入的參數(shù)
回答：這個bug不是一般場景下必現(xiàn)的，操作的步驟有點復(fù)雜，我在發(fā)現(xiàn)這個bug的時候同樣的操作步驟也不是每次都出現(xiàn)，我把發(fā)現(xiàn)bug的步驟一一列出來，然后你試著在你的環(huán)境下操作一下，如果不能必現(xiàn)，再來我這測試環(huán)境看一下，我先保留這個測試的場景。
10. 開發(fā)提測明顯不符合質(zhì)量要求
- 錯誤做法
哎，將就著測吧，通通提bug唄
埋怨開發(fā)提測的啥玩意
嘲諷開發(fā)，比如你這啥水平啊，是不是技校畢業(yè)的
正確做法
開發(fā)提測后進行冒煙測試，發(fā)現(xiàn)主要流程無法走通，冒煙測試不通過，將冒煙測試報告發(fā)送給開發(fā)，抄送相關(guān)產(chǎn)品負責(zé)人員等，將冒煙情況說明在測試報告中，為保障后續(xù)的測試進度與流程，望相關(guān)開發(fā)人員盡快修復(fù)問題，保障產(chǎn)品按時提測，進行測試。
11. 當(dāng)開發(fā)推脫忙拒絕case評審時
- 錯誤回答
1、不評審出了問題你負責(zé)啊
2、有啥忙的，平時也不見你這么忙
3、那就不評審了唄
正確回答
測試用例的編寫是從需求文檔分析中提取本次的測試要點，項目開發(fā)過程中對于技術(shù)的具體實現(xiàn)是否與產(chǎn)品需求一致，希望你（開發(fā)）與產(chǎn)品一起參與一下評審，這樣我們從不同的角度去過一遍測試用例，為了保障測試用例的覆蓋度，提前將未從技術(shù)實現(xiàn)的細節(jié)考慮到的用例暴露出來，這方面還就需要你參與一下，如果實在沒有時間評審，我們就郵件進行一下用例評審，我將測試用例發(fā)出，你看后回復(fù)一下郵件也可以。
12. 當(dāng)開發(fā)反復(fù)修改bug不正確時
- 錯誤做法
1、埋怨開發(fā)啥水平啊，改了幾次還是這樣
2、讓別的開發(fā)替改
3、抱怨，干脆不測得了
正確做法
將這個bug出現(xiàn)的場景參數(shù)一一列出，調(diào)用的接口等描述出來，查看開發(fā)代碼，將bug出現(xiàn)的問題幫助定位。
13. 修改bug引起別的bug
- 錯誤回答
1、讓你改一個bug，你還整出2個bug了
2、你這也太不認真了吧
3、再這樣下去，測不完了
正確回答
剛才的bug修復(fù)之前這塊是沒問題的，當(dāng)這個bug修復(fù)后，這個模塊的這個功能異常，引起了這個問題（將這個問題描述清楚場景），是不是這2個模塊耦合度有點高，咱們看看這兩個模塊吧。
14. 當(dāng)開發(fā)找你復(fù)現(xiàn)的bug的時候
- 錯誤回答
1：操作步驟在那兒，瞎嗎
2：必現(xiàn)的bug你都復(fù)現(xiàn)不了，撒幣嗎
3：一個微笑的表情
4：反正 LOG/抓包已經(jīng)在那兒了，剩下的自己看著辦吧
5：你來打我呀，你來打我呀，呵呵呵~~~
正確回答
我操作步驟是不是寫的有歧義，這個bug我是這樣復(fù)現(xiàn)的。。。
寫在后面的話：
站在項目角度、客戶角度，有問題解決問題，資源總是有限的，一定是有取舍的，至于具體的措辭態(tài)度，對人下菜了，畢竟有的開發(fā)喜歡攻，有的開發(fā)喜歡受
