做一個靠譜的軟體測試工程師：進行有效地溝通

mp.weixin.qq.com

在寫上一篇靠譜文章的時候，王豆豆就計劃再寫一篇了，但依王豆豆的性格是不拖到最後一刻鐘是不會開始寫的，感覺王豆豆以後可以改名為王拖拖了，拖延的本性看是改不了（傷心中），不然哪來古人云：江山易改，本性難易呢！

不多說，今天王豆豆就給大家講講做一個靠譜的軟體測試工程師還需要哪些技能：

+ 軟技能

+ 溝通

+ 其他軟技能

上一篇靠譜文章中寫到的技能，稱之為硬技能，可以這樣說硬技能決定了你在職場道路上走多快，那麼軟技能就是決定了你能在職場上走多遠，而對於軟體測試人員來說良好的溝通是不可缺少的。

為什麼溝通會成為軟體測試人員必備軟技能？

是因為軟體測試人員不像開發人員可以少說多做，開發人員就算是溝通能力不高也能在職場中上升，但你一定會注意到在職場中一定是那些溝通能力強的開發人員上升特別快，如果上升了且溝通不咋的，那麼一定是那類編碼技術特別牛，缺一不可的開發人員，但這類開發人員只適合做事，不適合做管理。

如果你覺得你的技術也能讓領導和夥伴忍受你的壞脾氣，那麼你可以不用想著怎麼提高你的溝通能力。

不過我們始終是那一類普通的角色，所以提高你的溝通能力，避免做無效溝通也是我們的技能中必不可少的一部分。

那我們應該怎麼提高自身的溝通技巧呢？

1.明確溝通的對象

與測試人員打交道一般來說只有二類人群：

一類是開發人員

與開發人員溝通最多的就是針對BUG，這是不是一個bug？如果是bug需要怎麼改？什麼時候能改好等等問題。

另一類是產品經理

與產品經理溝通主要是圍繞需求，開發和測試對需求理解不一致時，找產品確認；對需求有疑問的，找產品諮詢；這個需求本次迭代需不需要做，等等。

針對這二類人，其中又以與開發人員打交道最為居多，當然並不是說我們只與這二類人溝通，只是說相對別的團體，這二類溝通居多，有時我們也需要與項目經理、UI等溝通，只不過相對少一些。

2.有效溝通

溝通就是人對人說話，如果對方能理解，並且能解決問題，那麼溝通就算有效。

溝通說起來簡單，做起來卻相對很難，與對方交流時，對方與你不在一個頻道上，說這事扯到另外一件事上去了，有時真想仰天長嘆，老天爺，請賜一個懂我的開發。

為什麼在與其他團隊交流時容易起衝突呢？

最近這幾天正在成甲老師的《好好學習》，其中有這樣一段話：

當我們感到自己的觀點、尊嚴可能會受到挑戰的時候，我們第一反應不是思考對方的挑戰和質疑是否合理，而是：有人敢反對我，和他干，這時候，我們的習慣性防衛就產生了。

我們之所以會習慣性防衛，還有一個很重要的因素：我們會把別人對我們觀點的質疑，理解為對我們自己的否定。換句話說，我們常常不自覺地把「我」和「我的觀點/行為」綁定在一起。

比如，別人和我開會討論時說：「成甲，你上次項目做得太爛了。」此時，我的第一反應可能不是去思考我的項目是不是很爛，他說得對不對；相反，我覺得他是在針對我、指責我，我就會回擊：「胡說，你做項目才爛！」這樣，我把別人對自己觀點/行為的質疑理解為別人對我這個人的質疑，從而激發起自己的習慣性防衛。

想來，我們每個人都是這樣，每當別人在跟我們說事時，我們自己總能將它上升到是對自身的攻擊，而不能平心近氣地就事說事。

比如，在測試過程中，遇到某個問題：

測試人員：XXX，這個地方你代碼寫得不對，有bug。

開發人員（心理已經開罵了）：不會的，在我的電腦上都是能實現的，沒問題啊。

測試人員默默地再次測試，發現問題還是存在。

測試人員：XXX，這確實是一個bug，簡訊始終推送不成功

開發人員：不可能，你配置數據了沒？

開發人員：你會不會測試哦？

測試人員：。。。。。。

面對這樣的情況，開發和測試都認為自己是正確的，這從一開始就是敵對，如果碰到一個很自我的開發很容易就起衝突了，那如果碰到這類開發，我們應該怎樣去溝通？

王豆豆經常使用的方法就是一問二試三確認：

一問

比如剛才那個簡訊推送不成功的場景，遇到這樣的問題，首先找對應的開發確認。

王豆豆：XXX，給用戶發送簡訊，需要在哪裡配置數據么？從哪個表裡面取用戶的手機號？

開發人員：需要在系統管理界面配置一個定時任務，定時觸發發送簡訊任務，用戶的手機號從user表中取。

如果是聰明的開發會將配置界面截圖發給測試，如果遇到不聰明的，那就直接問他要。

二試

根據開發說的操作，在測試環境上配置，並且去查相關的表，確實表中的數據是否正確存儲？值是不是取正確了？

配置和查表完成之後，就再次測試，確定結果。

為什麼會做這樣一個操作？目的就是為了防止是自己沒有配置數據或是測試環境的問題而引起的BUG，從而避免開發人員覺得測試人員不夠專業。

三確認

如果經過前面二個步驟，BUG還是出現，這時可以找開發確認了。

王豆豆：按你剛才說的配置了，為什麼簡訊還是沒有推送成功？查看了定時任務已經執行了，你看下。

同時附上配置的截圖，定時任務和bug出現的截圖（相關的截圖)。

大多數的開發這時都會想是不是代碼出bug了，檢查一下。

所以按上面幾步執行，基本都不會出現衝突，有問題改問題，沒問題也不會造成開發和測試雙方純潔的友誼，哈哈。。。

上面這種場景是針對需求很確定，開發在實現需求時出現的問題，測試人員在與開發確認問題時的溝通手段。

另一種情況是需求不確定，開發和測試對同一個功能有爭議，比如開發覺得可以這現在實現，測試覺得可以做得更好。

比如，以下這個場景：

王豆豆：XXX，搜索條件中的申請時間少了默認時間，建議加上。

開發人員：。。。。（開發人員甩不甩你）

如果碰到這種情況，開發不願意改，覺得可有可無，而測試人員從用戶體驗性方面考慮又覺得一定需要，那這個時間千萬不要和開發爭吵，直接去找產品經理確認，產品經理說需要，那開發人員一定會改，如果產品經理說不需要，作為測試人員也不必糾結這這個問題。

一般來說在溝通中做到以下幾點：

1.需求不確定，找產品經理確定

2.BUG不能確定是否需要修改，找項目經理/測試經理/開發經理確定

3.確定的BUG，直接提缺陷管理平台

4.不確定是否BUG，先找開發人員確認，確認的步驟可以試下一問二試三確認

特別是針對某BUG，開發人員不願意修改的情況，千萬不要和開發人員直接起衝突，但也不能聽開發人員說這個不重要，不需要修改這些屁話，直接發郵件找上級確定是否需要修改，在郵件中寫清楚從測試角度這個bug為什麼必須要修改？如果不修改會造成什麼問題等情況。

這裡其實是一個面試題：

當你提出一個BUG時，面對開發人員不願修改，這時你會怎麼處理？

答案就在前面，需要自己總結和歸納。

最終，不管這個bug是不是要被修復，都需要記錄到缺陷管理平台，只有記錄在這個平台上，才算是你對這個測試點有測試到，如果後期這個地方真出現問題了，你說你測試過，但開發說不需要修改，這時就口說無憑，誰又會相信你呢？

在項目中經常會開一些討論會，其實就是撕B大會和甩鍋大會，溝通技巧和前期留下的做事痕迹（郵件）就變得很重要了，當然我們做這些並不是為這一刻，而是這些做事方法也是專業的體現。

溝通作為測試人員重要軟技能之一，測試人員一定要學會進行有效地溝通，在溝通中既要堅持自己的觀點，又要聽取其他人員的意見，避免衝突，始終堅守溝通是為了解決問題，而不是個人與個人的PK賽，最終能將問題完美解決，而又不損同事情誼。

經常聽人說測試人員在項目團隊中沒有發言權，其實測試人員並不是沒有發言權，而是需要你在發言的時候需要提出有理有據的理由，有實際的解決方法，這樣其他團隊的人員才能信服，才能提高項目質量，從而體現測試人員的價值。

今天寫的測試人員的溝通軟技能，軟體測試人員想做軟體測試工作必須還需要掌握其他的軟技能，歡迎大家告訴王豆豆你經常使用的軟技能還哪些？

推薦閱讀：