【雜談】作一個不被開發鄙視的測試工程師

忙忙碌碌，不知不覺在新公司已經3個月了。尤爲是最近一段時間，異常的忙，可是我仍然會抽出必定量的時間來作些開發。
之後成熟的話，打算輸出一個手把手開發的系列，分享給更多的測試童鞋。

前幾天跟羣裏一位小夥伴聊天，聽到了一個關鍵詞。相信這也是不少測試童鞋都有過的體會，感受測試容易被開發鄙視，得不到尊重。

既然今天也沒什麼技術向的內容分享，那就隨便聊聊吧，以一個入行3年多的測試小兵的角度，談談個人感覺。

1、聽聽測試跟開發都吐槽對方什麼？

1.來自開發的問候

因爲忙於各類業務，因此認識了不少的開發童鞋。接觸的多了，你們話題也就聊開了。由於他們也會跟不一樣的測試人員合做，因此我
偶爾就能聽到開發對測試的一些吐槽。

「那XX，稍微有點不對，直接反手就是一個bug單，問都不問」；
「你這算啥，你沒看那XXX，說問題就一張截圖，無語」；
「哎，如今測試都不看數據庫的麼？前端的鍋bug提給我幹嗎？」... ...

不知道你們是否也曾經聽到過相似的吐槽，我以爲場景很真實，我相信必定有測試人員是這樣作的。別問，問就是我也曾...

其實對於上述的測試童鞋的表現，我以爲一般是2種狀況：

• 不知道怎麼去定位bug，點出問題後只能全拋給開發本身去排查
• 知道怎麼定位，可是沒有去進一步定位（太忙 或者 懶得動）

2.來自測試的問候

就是最近，咱們組裏新來了一位測試童鞋。雖然人家是新來的，可是履歷仍是很是棒的，在阿里、華爲都待過。
而後晚會的時候就聽到新童鞋吐槽樓上的xx開發，幾個小功能竟然能有十幾個bug。
bug多就算了，最可氣的是，被發現了bug還不認可，一會本身偷偷改了，再跟你說這功能沒問題...
不知道你有沒有遇到過這樣的開發人員呢？

對於這位開發的表現，我以爲多是這樣的：

• 專業能力差，bug多
• 專業能力還行，不認真，沒自測，沒責任心
• 人品不行，這我的作任何工做均可能會引發身邊合做的人反感。
  

2、我和開發的「恩怨情仇」

其實你們在平常工做中講得就是一個「合做」，可是對於測試這份工做，你進行的順利與否仍是挺"看臉"的。

若是你測試的業務，對於的開發是一個自我要求高，技術能力很強的大佬，那麼基本上你的case會跑的很順利，有問題也不多。
反之，開發能力差還蜜汁自信，你就會很心累，各類測不通。

個人記憶裏，我接觸的到開發童鞋整體都還不錯，起碼溝通起來沒有不愉快過。因此，一般來講，我跟這些開發相處的都不錯，
天然就沒有「無間道」了。

可是對於上面提到的那種「毒瘤」，天然也不能慣着。若是對方不自測，那我會去了解下爲何不自測。若是真的是由於太忙，那我以爲
也是能夠給與必定的理解。
若是就是那種不自測，拿測試當「保姆」的，對不起，冒煙測試3次不過，打回不測了。把涉及到此需求的各方人員
都拉在羣裏，說明緣由，開發自測後直接上線。

其實上面說的狀況天然是我最不想看到的，可是這是由於對方實在可氣，致使你的工做不能順利進行，可是我相信大多數的開發童鞋仍是頗有
責任心的，你們都是一個訴求，功能沒問題，如期上線。

3、我在工做中是怎麼作的？

首先，我以爲測試的工做形式絕對不是一成不變的，仍是要以適應當下的形式才行。

好比說我上個東家，雖然說是個三線互聯網公司，可是也是港股上市，業務穩定，大幾千人。這樣的公司一般不少流程已經比較規範了，好比從需求的
提出，到最終的上線，能夠較好的按照比較標準的流程走下來，具體流程你們都知道，就不贅述了。

那如今的狀況就不同了，我如今的是創業型公司，處於C輪。需求多、測試人力不夠（一直在招，合適的難找）、流程不規範，這些缺點都有。這時候
還用以前的那套顯然啥都作不了了。

就拿最近負責的業務來講說，我在測試工做中一般會去作什麼？

1. 需求急，短期上線——關鍵詞【溝通】

其實這種狀況，在穩定和創業型公司都會遇到，只不事後者這種狀況更多見。這時候，熟悉需求確定仍是首要的。無論你有沒有直接參與需求的評審，都要
找涉及需求的直接人員進行有效溝通，注意是有效溝通。

找到需求的推動人，肯定上線週期，提測時間，好規劃測試時間，以及對於需求的一個測試重點分佈。另外，還要把發現的一些風險點或者測試覆蓋不到的地方
及時的拋出來，羣策羣力一塊兒想辦法。千萬不要有阻塞點卡着 你不說出來，這樣的話萬一致使延期的話，鍋可就是你的了。

2. 需求描述簡單，不仔細——關鍵詞【梳理】

這狀況也是伴隨着上述的狀況而生，由於這種需求下很難有完整的需求文檔描述以及原型圖等等， 那麼這個時候開發在設計的時候也可能考慮不全。那麼，既然我
又不能直接撂挑子無論不顧，那我也只能盡我本身一份力，去幫着查漏補缺。

好比，最近的需求測試當中，我就要測試一個job接口，這個接口用來按照策略生成任務的，數據很重要，天然這個部分就是測試的一大核心重點。

重點需求重點對待，不只要看功能頁面上的展現，還要去查詢各類表，去肯定數據的準確性。
這個需求由於測試數據很差準備，在前期與開發溝通的時候，瞭解了涉及到的各類表之間的關係，本身去寫sql造測試數據。

在驗證結果的時候，我還會去查日誌，一些關鍵點沒有日誌的話 提醒開發童鞋補上，方便驗證。而後在一次次的測試中，再次梳理接口的處理邏輯。
看似正確的處理邏輯，當設計了足夠多的場景數據去測試的時候，果真，發現了2除邏輯上的疏忽。

開發童鞋連贊發現的好，立馬找來產品確認下是否須要補齊這個邏輯。

另外，在我查詢各類表的時候，開發童鞋還反問我：「你還查庫呢？我看不少測試都不查數據庫的，挺好的」

3. 發現問題，如何更好的提bug——關鍵詞【謹慎】

提bug，那確定是咱們工做中的一大重點內容了。發現問題，我以爲能夠不用當即去提bug單，首先我會在個人case腦圖後加標記，出現的什麼問題。
而後再結合個人時間安排，以爲定位bug的深度。 最最最不濟，你也要肯定這問題是能復現出來的。

其實定位bug仍是經常使用的那些方式，看請求，確認參數返回，查數據，看日誌，依次來大概肯定下是誰的問題，這時候你再提單會好一些。
固然了，確定有一些我不能肯定的問題，那麼我可能會提給這個功能的最直接的那我的。

此外！！！還要多加一句：「這個問題可能不是你致使的，若是你發現不是你的問題，你直接將bug流轉給對應的人就好」。

對應沒時間寫測試用例，這個事情也很常常了。我以爲這種需求下，在你熟悉大概狀況後，能夠邊測邊寫，再不濟的話，測試過的點和考慮到的場景務必要記錄，
還有重要的溝通內容，截圖等等，這是你工做細節的證實，也是你往後甩鍋的證據。

4. 無心之中，「秀」一下你的代碼

其實不少開發會鄙視測試的最直接的因素，就是測試不寫代碼。 我在上一家測試一個專項的時候，跟組裏的高T開發合做過，結項的時候，他表示以爲我
是一個不錯的測試，他以爲不會寫代碼的測試不能算作一個合格的測試。

其實這位大佬的言論在我看來仍是有些偏激的，可是這確實就是表明了一部分開發的想法。

就包括我如今，在開發debug的空閒期，我也會打開個人編輯器去繼續寫一些有用的代碼，有些開發看到後，會好奇的問：你在寫什麼代碼呀？這個時候你就能夠
扯一波了，千萬不是吹噓本身，表示你用代碼在作一些有利於提效等等的事情，儘管你的開發水平不高，可是開發人員這時候仍是會對你另眼相看，給你打上一個會
寫代碼的標籤。

可是，咱們別忘了，測試學習寫代碼，最終目的就是要去提效，提升工做效率，作一些對你們有意義的事情，讓代碼發揮出價值。千萬不要本末倒置，爲了寫而寫。

4、小結

思路比較雜亂，想到哪說到哪，最後點一下主題，如何不被開發鄙視。

首先，我以爲測試童鞋絕對不要妄自菲薄，其實你能夠這樣想一下，多數的開發人員每天的工做內容也是業務的CRUD，跟你的業務測試不會高到哪裏去，若是你換了份開發
的工做作，你熟練後一樣能夠達到他們水平。 工做沒有貴賤之分，互聯網行業從業人員這麼多，那是否是全部人都要去作開發？

再者，你的工做內容並不侷限你的發展，你代碼該學學，熟練了，簡單的算法也能夠搞一搞。千萬不要知足於現狀，這一點是最重要的，就算你投身其餘行業，亦是如此。

最後，在測試工做中，扮演好你這個角色，作一個有責任心、謹慎、對團隊有幫助的人，試問，這樣的一我的，誰會看不起你？

以上都是個人我的愚見，歡迎你們分享一下本身的工做狀態內容。