這些不要做
  如果不緊急，不要分散開發人員的注意力不要馬上走到他的辦公桌前。首先通過Messenger詢問或提前安排會議。我意識到，一旦自己開始寫代碼的時候，當有人過來打斷我的時候，我需要花費大量的時間和精力才能再次進入之前寫代碼的沉浸狀態，這種中斷根本不會增加生產力。
  別害怕尋求幫助你不可能什么都知道，問別人是有沒關系的，因為這比假裝你很酷要好！不過要確保你理解了答案，不要問同樣的問題兩次。大家都在同一條船上，如果每個人都有一支槳，我們就可以朝著一個方向前進，這對每個人都有好處。
  不要相信開發人員的話您需要找到證據來證明開發人員對“一切都應該沒問題！”或“我只是改了代碼中的一個字符串，它不會破壞任何邏輯”的信心。
  不要責備不要固守消極，嘗試解決問題，對事不對人。稍后我們可以決定如何避免將來出現類似問題。沒有人是完美的，錯誤是不可避免的。主要目標是有能力做出健康的反應，然后做好自己的就好了。
  別偷偷摸摸直接給開發人員分配給缺陷與跟開發人員在未經QA批準的情況下關閉bug有異曲同工之妙，這可能會令人生氣的。
  不要對開發人員進行事無巨細的管理“你檢查缺陷了嗎？”，“現在怎么樣？”，“你什么時候修復錯誤？”。這很煩人，他們不能更快地解決問題。只需將自己置于開發人員的位置即可。
  別把事事都放在心上，臉皮可以厚一點不要情緒化，不以物喜，不以己悲，不需要對別人的無意間的言行睚眥必報。你要同傲慢的人打交道，它實際上可以應用于任何人。這就是為什么厚臉皮和委婉的表達是必須的。
  可以這么做
  與開發人員交流知識讓他們了解您的測試方法，為每個與你合作的開發人員找到“access_key”，高告訴他們你會如何進行測試，這可以幫助你避免部分錯誤。但是，由于一些原因，這并不總是可能的。，時間不夠。其次，企業流程不允許這樣做。最后，開發者出于多種原因不愿意與某人合作。但是，如果你能找到我上面提到的“access_key”，從長遠來看，保持健康的關系會容易提升產品質量。
  說服如果你想在中得到一些非測試方面的提升，這是一項有用的技能。尋求支持并將您的計劃變為現實，不過如果你在你的陳述中感到孤獨，也許你的計劃或想法是有改進空間的。所以，不要為了說服而說服，讓別人接受你并不總是正確的事實，傾聽和傾聽你周圍的人。
  說實話否則，它會很快毀掉你的聲譽?；蛘哌@取決于你是一個多么好的騙子，不是每個人都是老羅。
  準備好為你提的bug辯護有時候你必須捍衛需要修復的缺陷的重要性。但是你必須在你的陳述中說明自己的觀點，讓別人信服。隨著時間的推移，這會讓你得到其他人的信任并節省企業的資金成本。
  在壓力下保持冷靜我知道，這很難。當每個人都不斷催促你或你的團隊時，你很難不乖乖就范。然而，說“不”是我們的一部分，即使這不是流行的觀點。當然如果有人把你推到墻上或用槍指著你的頭，這條規則就不起作用。
  與開發人員討論測試用例根據我的經驗，這很難做到。這需要雙方的時間和奉獻精神，魅力和測試同學的強大說服力。我已經這樣做了一段時間，但我無法采用這種方法。我從與開發人員的此類會談中看到了巨大的好處。但是，我可能看不到的東西可能會告訴我相反的情況。你怎么認為？
  在bug描述中要準確如果可以，請使用開發人員的語言。在其他情況下，讓你的表述盡可能的簡單。它應該是瑞典語中的“lagom”。具有良好的規模結構并為開發人員提供足夠信息，讓別人知道你描述的是到底是什么。
  鼓勵隊友深入了解產品團隊中的這種意識將減少愚蠢的bug數量。根據我的經驗，低級的bug會消耗大量精力來報告它們。這些bug直接就預防住，讓我們專注于更重要的事情。而不是讓我們報告錯誤的*字體大小，*測試的邊緣情況、安全性、性能等。
  要有耐心不是每個人都是好相處的，要應對困難的、自戀的人。這是適用于任何人的一般性規則。